Skip to the tool
OnPageKit

Deprecated HTML Tags Checker

Find obsolete elements and presentational attributes in pasted markup.

a template, a component, a whole page

Everything happens in this tab. The tool reads the markup you give it and has no way to fetch a page, which is why it wants source rather than an address.

Outlook for Windows has drawn email with the Word engine since 2007 and ignores most layout CSS, so table attributes are the correct technique there. The option keeps them listed and stops calling them faults.

Elements
0
Attributes
0
Distinct
0
Inert
0
  • No obsolete elements and no presentational attributes in this markup. Note that valid is not the same as accessible: this check says nothing about labels, contrast or reading order.

Everything runs in your browser. Nothing you type is sent to a server.

Found a bug in this tool? Report it.

Share this tool

What this deprecated HTML tags checker looks for

Paste a template, a component or a full page, and this deprecated HTML tags checker walks the markup for two separate things: elements the HTML Living Standard has declared obsolete, and presentational attributes that CSS replaced. Each hit comes back with the line, the element it appeared on, and the declaration or tag to write in its place. Counting matters as much as naming, because forty font tags in one template is a search and replace, while one in a legacy include is an archaeology problem.

Parsing happens in this tab, on the text in the box. Nothing leaves the browser, which also explains why the field asks for source instead of an address: a page cannot read another site's HTML without a server standing in the middle, and that server would have to see your staging URL.

Obsolete is a promise to old pages, not a licence for new ones

There is a gap in HTML between what user agents must handle and what authors may write, and every element listed here lives in it. Browsers keep drawing <center> and <font> because millions of documents depend on them and nobody wants a blank screen. The specification is separately explicit that these must not appear in new markup. Both statements are true at once, which is why "but it works" never settles the argument.

A second group never worked again. <blink> stopped animating when Firefox 23 dropped it in 2013. <applet> lost its runtime when browsers removed plugin support. <keygen>, <isindex> and <menuitem> are gone from every engine. Markup like that is not a style problem — it is dead code occupying space in a file somebody still has to read. The tool separates the two cases, because they deserve different urgency: one is tidying, the other is deletion.

The real bill, which is not a ranking

Nobody should promise that removing a <font> tag moves a search position. Google parses this markup happily and has never suggested otherwise. The costs are elsewhere and they are more concrete.

Accessibility is the sharpest one. A <marquee> moves text that a reader cannot pause, which fails WCAG 2.2.2 outright and makes a paragraph unusable for anyone with a vestibular disorder or a reading difficulty. A layout table carrying valign and cellpadding is announced by a screen reader as a table with rows and columns that mean nothing. And <acronym> was replaced by <abbr> partly because assistive technologies had two elements to support where one would do.

Maintenance is the quieter one. A colour written into a hundred <font> tags cannot be changed by a stylesheet, so a rebrand becomes a find and replace across templates instead of a variable. Every presentational attribute is a rule that CSS cannot override without !important, and each one makes the next developer trust the stylesheet a little less.

Where the exceptions are

Two exceptions are worth knowing before you delete anything. Email is the first: Outlook for Windows has rendered messages with the Word engine since 2007 and ignores most layout CSS, so bgcolor, valign and nested tables are the working technique there rather than a mistake. Tick the email box and the tool keeps listing them while dropping the scolding.

The second is width and height on media. On <img>, <video>, <canvas> and <iframe> those attributes hand the browser an aspect ratio before the file downloads, which is what keeps the page from jumping. This checker deliberately ignores them there and reports them only on tables, cells, <hr> and <pre>, where they really are leftovers.

When the markup is clean here, the heading structure checker covers the outline, the image alt checker covers the images, and the mixed content checker covers anything still loaded over plain HTTP.

Frequently asked questions

If browsers still render these tags, why should I care?

Because rendering is a promise browsers make to the past, not to you. Vendors keep obsolete elements alive so that a page from 1998 still opens, and they say plainly that authors must not write new ones. The cost lands somewhere other than the pixels: a team member has to learn what plaintext does before touching the file, a design change means editing markup instead of a stylesheet, and an assistive technology gets a presentational element where it expected a semantic one. None of that shows up as a broken screenshot, which is exactly why it survives for years.

What is the difference between obsolete and invalid?

Obsolete means the specification lists the feature, describes what user agents should do with it for compatibility, and forbids authors from using it. Invalid means there is no such feature at all. The practical difference is that a validator flags an obsolete element with a clear message about the modern replacement, whereas invented markup produces a parse error or is silently treated as an unknown inline element. This checker only reports things that were once part of HTML and no longer are; it does not guess about markup it has never heard of.

Does obsolete markup hurt my rankings?

Not directly, and it would be dishonest to sell it that way. Google parses obsolete elements without complaint and has never listed them as a ranking factor. The indirect route is real but narrow: layout tables and font tags tend to travel with a page that is hard to read on a phone and slow to change, and both of those are measured. Fix this markup because it makes the codebase cheaper and the page more accessible, not because you expect a position to move.

Are b, i, u and small deprecated?

No, and the checker says so instead of flagging them. HTML5 kept all four and redefined them in terms of meaning rather than appearance: b marks text set apart without extra importance, i marks an alternative voice, s marks something no longer accurate, and small marks side comment or small print. The elements that genuinely went away are font, center, big, strike and tt. If a checklist tells you to remove every b tag, that checklist stopped being updated around 2011.

Why does the tool leave width and height on images alone?

Because there they are not presentational. Width and height on img, video, canvas and iframe give the browser the aspect ratio before the file arrives, which is what stops the page jumping as it loads. The same two attributes on a table, a cell, an hr or a pre are the obsolete ones, and that is the only place this tool reports them. Stripping them from every image is one of the more expensive pieces of advice a generic checker can give.

Related tools

Updated