Check HTML structure with line-and-column errors — tag pairing and nesting, unquoted or duplicated attributes, unterminated raw text. Structural checking, stated plainly: not a full W3C validation, and a pass here is the floor, not the ceiling. Free, no sign-up — runs locally in your browser.
What this checker is — and is not
Plainly: this is structural checking, not full W3C
validation. It answers one question — is this document
put together correctly? Tags opened and closed in the right
order, attributes quoted and unique, raw-text elements paired.
It does not answer the bigger question — does this document
obey every rule of the HTML specification? That is the W3C
validator's job, with its content models and semantics, and
for a production page you should use it too. The structural
layer is worth checking separately because it fails first and
weirdest: one unclosed <div> on line 40
silently adopts everything after it, and the symptom shows up
in the footer. Browsers will never tell you — absorbing broken
structure and guessing is their job. This checker's job is to
not guess.
How to use this tool
- Paste the HTML, upload an .html file, or drop one on the panel. Fragments are fine — a DOCTYPE is reported on, not required.
- Press Check HTML. A sound document gets a short report: element and attribute counts, DOCTYPE status, raw-text elements found.
- On a failure, you get the first structural error with its line and column — fix it and check again; later errors are often the same fault echoing.
- When it passes, reach for the HTML Formatter here to tidy the document, and the W3C validator for the full specification pass before you ship.
Exactly what is checked
Pairing and nesting. Every non-void element
must close, in the reverse order it opened; a mismatch names
the expected and found tags at their positions. Void elements
(img, br, input, …)
must not have end tags. Attributes. Values
must be quoted — single or double, your choice; a valueless
attribute is fine (that is how disabled works), an
= with no value is an error, and the same
attribute twice on one element is an error, because browsers
silently keep the first and drop the rest.
Raw text. script,
style, textarea and
title contents are scanned as text — angle
brackets inside them are not markup. Not checked:
the HTML content model, required attributes, unknown elements,
spelling of anything, CSS and JavaScript contents, and whether
your links point anywhere. That boundary is deliberate and
stated here so a green result is never oversold.
A note on strictness
HTML legally allows some end tags (</p>,
</li>, table cells) to be omitted. This
checker requires them anyway — well-formedness is the stricter
discipline that XML, XHTML, template engines and build tools
all expect, and markup that satisfies it works in every one of
those contexts, while markup relying on omission works in
exactly one: a forgiving browser. If you paste a fragment from
a templating system, expect the checker to also complain about
the unmatched pieces the template adds elsewhere — check whole
rendered documents where you can.
Frequently asked questions
Is this the same as the W3C validator?
No — and the difference matters. The W3C (Nu) validator checks your markup against the full HTML specification: content models (a <div> inside a <p>), required attributes, obsolete elements, ARIA rules, document semantics, hundreds of rules. This checker verifies the layer underneath all of that — whether the document is structurally sound: tags paired and nested correctly, attributes properly quoted, no duplicates. If it fails here, it fails everywhere. If it passes here, it may still fail the W3C validator, and for production pages you should run that too. Think of this as the spell-check; W3C is the editor.
Why is an unquoted attribute value (href=/foo) flagged? Browsers accept it.
Browsers accept it the way they accept most broken markup: by guessing, inconsistently across edge cases. An unquoted value ends at the first space or >, so href=/foo bar=baz quietly becomes two attributes, and a value containing = or a backtick behaves differently in old engines. The HTML spec itself calls unquoted values a parse error. This checker follows the spec, not the browser's tolerance — the point of validating is to find what tolerance hides.
My document has no DOCTYPE but everything is paired. Why the warning?
Because a missing DOCTYPE switches browsers into quirks mode — a compatibility behaviour from the early 2000s that changes box sizing, table layout and other rendering rules. Your structure is fine, so it is a remark rather than an error, but it is the single highest-impact one-line fix in HTML: add <!doctype html> as the very first line and the document renders in standards mode everywhere.
Does it check the contents of <script> and <style>?
No. Their contents are raw text, not markup: the checker scans past them (while still requiring their end tags to pair up), and does not judge the JavaScript or CSS inside. A stray '</div>' inside a script string will not trigger a false error here, which is more than can be said for naive tag counters — but it also means a genuinely unclosed script is reported as an unclosed script tag, not as a JavaScript error. Validate JS and CSS with their own tools.
What about optional end tags — </p>, </li>, </td> are legal to omit?
They are, in HTML — a <p> is implicitly closed by the next block element, an <li> by the next <li>. This checker requires explicit pairing anyway, and says so up front: it checks well-formedness, which is stricter than HTML's minimum. Explicit end tags are what XML, XHTML, templating engines and every parser you'll feed this markup to expect; documents that rely on implied closing break the moment they leave a forgiving browser. If your house style deliberately uses HTML's omission rules, treat those specific reports as expected — but know that is what they are.
It says my file is fine but the page still renders wrong. Now what?
Structural soundness is necessary, not sufficient. Rendering problems with valid structure usually live in the content model (elements in illegal parents — run the W3C validator), in the CSS (the CSS Beautifier and Validator here can help), or in the browser applying quirks mode (check the DOCTYPE). This checker narrows the search: when it passes, you can stop wondering whether a tag somewhere is unclosed, which is the fault that produces the strangest, least localised symptoms.
Dev