HTML Validator

Front-end developers cleaning up markup before a launch, content managers pasting CMS output, and SEO specialists auditing template files all run into the same problem: broken HTML that browsers hide but crawlers and screen readers punish. This validator checks your markup for unclosed tags, duplicate IDs, missing alt text, deprecated elements, and heading skips, then reports every finding with its line number. Everything runs locally, so staging pages and client code never leave the browser.

HTML Input

Findings

How the Validator Parses Your Markup

The validator walks the input character by character, tracking open tags on a stack. When it encounters a closing tag it compares it against the most recent open tag; a mismatch is reported immediately, and any tags that were left open between the two are flagged as unclosed. Void elements like img, br, and input are recognized from the HTML5 specification and never pushed onto the stack, so they cannot produce false unclosed errors.

Attribute parsing handles quoted and unquoted values, detects duplicate attributes on the same tag, and records every id for cross-document uniqueness checks. Comments and CDATA sections are skipped entirely so markup inside them does not trigger findings. The doctype, html lang attribute, meta viewport, title, and first h1 are each checked once at the document level.

Error vs. warning

Errors are structural problems that break parsing or accessibility: unclosed tags, missing alt text, duplicate IDs, stray closing tags, and a missing title. Warnings cover best-practice gaps such as a missing viewport tag, deprecated elements, heading level skips, and a missing lang attribute. Fix all errors before shipping; treat warnings as a prioritized backlog.

Line numbers you can trust

Every finding carries the line number where the problem starts. For unclosed tags the line is the opening tag, not the end of the file, so you can jump straight to the source. Mismatched closing tags report both the closing line and the line of the tag it was compared against.

Before and after: fixing a broken fragment

Before (3 errors, 2 warnings)

<html>
<head></head>
<body>
  <h1>Welcome</h1>
  <img src="hero.png">
  <center>Old tag</center>
  <h3>Skip</h3>
  <div id="x">A</div>
  <div id="x">B</div>
</body>

After (0 errors, 0 warnings)

<!DOCTYPE html>
<html lang="en">
<head>
  <title>Welcome</title>
  <meta name="viewport" content="width=device-width, initial-scale=1">
</head>
<body>
  <h1>Welcome</h1>
  <img src="hero.png" alt="Hero">
  <p style="text-align:center">Old tag</p>
  <h2>Skip</h2>
  <div id="x-1">A</div>
  <div id="x-2">B</div>
</body>
</html>

Use Cases

Developer	Production	Workflow
Validate a React component's rendered HTML snippet	Pre-launch check on a client's marketing page	Paste CMS output before publishing a post
Catch unclosed divs in a hand-written email template	Audit accessibility alt text across a redesign	Verify a landing page before ad spend starts
Check heading hierarchy in a documentation site build	Flag deprecated tags in a legacy codebase migration	Review a freelancer's delivered HTML before payment

Common Mistakes and Troubleshooting

The most frequent issue is pasting a fragment that starts mid-document and tripping the missing-doctype warning. If you only care about the fragment, ignore document-level warnings and focus on structural errors inside your markup. The second common issue is CMS editors that wrap content in extra p or div tags; the unclosed-tag findings usually point at exactly those wrappers.

If you see a mismatched-close-tag error on a tag that looks correct, check for an extra opening tag earlier in the file. Browsers auto-close unclosed p and li elements, which masks the problem in the rendered page but leaves the source invalid. Paste the raw source, not the browser's re-serialized DOM, so line numbers match your editor.

Best Practices for Clean HTML

Run the validator as part of your pull request checklist, not just at launch. Add alt text to every meaningful image and alt="" to decorative ones so the validator's img check stays clean. Keep heading levels sequential and use one h1 per page. Replace deprecated tags with semantic elements and CSS, and always include the doctype, lang attribute, and viewport meta for a standards-mode, mobile-ready document.

Pair this validator with an accessibility auditor for full WCAG coverage, and with a head-tag auditor for title and meta description quality. For bulk checks, run the validator on each template file in CI and fail the build when error count is above zero.

HTML Validator FAQ

How does this HTML validator differ from the W3C validator?

The W3C validator queues your page on a remote server and can take minutes during peak hours. This tool runs a full structural pass in the browser: unclosed tags, duplicate IDs, missing alt attributes, deprecated elements, heading hierarchy, and doctype presence all report in under a second. Nothing is uploaded, so staging pages behind basic auth stay private.

Does this validator check CSS or JavaScript syntax?

No. This tool focuses on HTML structure: tag nesting, attributes, required elements, and accessibility signals like alt text and heading order. For CSS syntax use a CSS validator, and for JavaScript use a linter or the browser console. Keeping the checks HTML-only keeps the parser small and the results focused.

Why does the validator flag duplicate IDs as errors?

The HTML specification requires every id attribute to be unique within a document. Duplicate IDs break label associations, fragment links, and JavaScript getElementById calls. Browsers silently keep only the first occurrence, so scripts that target the second element fail without any console warning.

What is a heading skip and why does it matter?

A heading skip jumps more than one level, such as an h1 followed directly by an h3. Screen reader users move through the page by heading level, and a skipped level makes the document outline confusing. Search engines also use headings to understand page structure, so a clean h1 to h2 to h3 hierarchy helps both accessibility and SEO.

Does the validator handle HTML5 void elements correctly?

Yes. Elements like img, br, input, meta, and link are void: they never have a closing tag. The validator knows the full void element list and does not report them as unclosed. Self-closing syntax such as img / is accepted but not required in HTML5.

Can I validate a full page or only a fragment?

Both work. Paste a complete document with doctype, html, head, and body, or paste a fragment like a block of markup from a CMS editor. Fragment validation skips checks that need a full document, such as doctype presence and the html lang attribute, while still catching structural problems inside the fragment.

Why does the validator warn about deprecated tags like center and font?

Tags such as center, font, marquee, and big were removed from the HTML5 specification. They still render in browsers today, but future browser versions may drop them, and they mix presentation with structure. The validator flags them so you can replace them with semantic elements styled through CSS.