Validators

HTML Validator

W3C markup conformance, checked by a real parser

Most HTML errors are invisible. The browser repairs them silently as it parses, so the page looks fine and the DOM you actually get is not the one you wrote - a mis-nested tag becomes a sibling, an unclosed paragraph swallows the block after it, a duplicate id makes `getElementById` return the wrong element forever.

Try:

Free, no signupNo account, no card
No AI in the score986 deterministic rules
Nothing publishedYour scans stay yours
Answers in secondsQuick scan, no browser

This validator reads the raw response body, before any JavaScript runs, and checks it against the HTML Living Standard's content model using a conformance tokenizer. That matters: a validator that inspects the rendered DOM is inspecting the browser's repaired version, and will tell you a broken document is clean.

You get the rule that failed, the message, and the exact line and column. Accessibility rules are deliberately not included here - those run against the live page in the Accessibility checker, and counting the same missing alt attribute in two places would inflate your score rather than describe your site.

Why this matters

It renders fine. So how can the markup be wrong?

Something is off and the cause is not obvious. A product card that collapses on one page only, a form that submits nothing, a script that keeps grabbing the wrong element, a preview that pulls the wrong text. People search the code and the theme settings first, because the page renders - and a page that renders looks like a page that is correct.

What it costs you when this is wrong

Two elements, one id, the wrong one updates
Ids must be unique. When they are not, every reference resolves to the first match only: the label focuses the wrong field, the in-page anchor jumps to the wrong section, and the script updates the wrong element. You usually find out from a customer saying that editing one item changed another.
A form inside a form submits nothing
The parser discards the inner form, auto-closes a paragraph before a block element, and injects the tbody you never wrote. Your CSS and your scripts then run against a tree that does not match your source. It shows up as an enquiry form posting empty fields, or a style rule that will not apply however specific you make it.
disabled="false" still disables the button
A boolean attribute is true whenever it is present, whatever value you give it. So disabled="false" on a checkout button disables it, and required="false" makes the field required. Nothing warns you, and the browser reports no error. You find out from the customer who could not complete the order.

Why run it here

Errors ranked by what they break
Each conformance rule carries its own weight. A wrong closing order or a duplicate id counts for far more than a table missing its tbody, so the report leads with the errors that change how the page behaves. A flat list in source order tells you where every error is, not which one to fix first.
The rule table is checked before your page
At start-up the rule set is run against a document known to be clean. If a rule name is wrong, the checker refuses to start and says why, rather than reporting a phantom error on every page it ever sees. It is there because that happened once: one rule name that did not exist would have invented the same error sitewide.
Markup is one layer of one scan
The same run parses your stylesheets against the W3C property grammars, follows every link, expands your structured data and renders the page in a real browser. 986 rules in total, and each finding cites the standard it comes from. Valid markup tells you the document is well formed, not that the page works.

This check runs on its own here, and as part of the full audit alongside the other 985 rules. Either way the findings carry their evidence and their citation, and the report is never published or kept.

How to fix HTML validation errors

Most validation errors fall into four families, and fixing them in this order resolves the majority of a typical page's list without touching the rest.

Close every element that requires a closing tag, working from the first reported error down — one unclosed element generates a cascade of errors below it that vanish when you fix the original.
Remove duplicate id attributes. An id must be unique in the document, and duplicates silently break label association, anchor links and scripts that query by id.
Nest elements legally: no block-level element inside a <p>, no interactive element inside another interactive element, and list items only ever directly inside <ul>, <ol> or <menu>.
Add the required attributes the spec demands — alt on every <img>, a non-empty <title>, a lang attribute on <html>.
Re-validate. Fix only real errors first and treat warnings as a second pass; the two are not equally urgent.

What happens when you run it

Enter your address
Just the domain is enough — example.com, with or without the https. No account, no card, no crawl of your whole site.
We render it like a visitor
Your page opens in a real browser and JavaScript runs to completion, so what gets audited is the page a person actually sees — not the raw HTML your server sent. A screenshot comes back with the report as evidence of exactly what we measured.
You get findings you can act on
Up to 986 checks run against that rendered page. Each finding names the rule, quotes the evidence found on your page, cites the public specification behind it, and says what to change. Nothing is a judgement call — run it twice on an unchanged page and the score is identical.

What runs this check

Real browser rendering
HTML Living Standard

Named because provenance is the product. Every finding in your report says which of these produced it, so you can check the reasoning rather than take a score on faith.

Questions

Is this the same as the W3C validator?: It checks the same specification - the HTML Living Standard - using an offline implementation of it. The W3C's own Nu Html Checker is the reference implementation; this produces the same class of finding, and reports line and column the same way.
Why does my page pass in the browser but fail here?: Because browsers are required to repair broken markup rather than refuse it. A nested anchor, an unclosed paragraph or a stray end tag all render without complaint - the parser fixes them and moves on. This validator reads the source before that repair happens, which is the only way to see them.
Does it check accessibility?: Not here. Accessibility is checked by the WCAG engine against the live rendered page in the Accessibility checker, plus a second engine (a second independent engine) for coverage. Keeping them separate is deliberate: running two engines' overlapping rules in one score would penalise the same defect twice.

Also checks

This page answers these searches too — they are the same job, so they share one page rather than being split across near-identical ones:

w3c validator
w3c markup validation service
html checker
html5 validator

Other checkers

Run the html validator now

No signup, no credit card. Quick answers in seconds; a full audit takes about a minute.

Run a free scan

No signup. No credit card. Nothing stored but the result.

HTML Validator

W3C markup conformance, checked by a real parser

It renders fine. So how can the markup be wrong?

What it costs you when this is wrong

Two elements, one id, the wrong one updates

Ids must be unique. When they are not, every reference resolves to the first match only: the label focuses the wrong field, the in-page anchor jumps to the wrong section, and the script updates the wrong element. You usually find out from a customer saying that editing one item changed another.

A form inside a form submits nothing

The parser discards the inner form, auto-closes a paragraph before a block element, and injects the tbody you never wrote. Your CSS and your scripts then run against a tree that does not match your source. It shows up as an enquiry form posting empty fields, or a style rule that will not apply however specific you make it.

disabled="false" still disables the button

A boolean attribute is true whenever it is present, whatever value you give it. So disabled="false" on a checkout button disables it, and required="false" makes the field required. Nothing warns you, and the browser reports no error. You find out from the customer who could not complete the order.

Why run it here

Errors ranked by what they break

Each conformance rule carries its own weight. A wrong closing order or a duplicate id counts for far more than a table missing its tbody, so the report leads with the errors that change how the page behaves. A flat list in source order tells you where every error is, not which one to fix first.

The rule table is checked before your page

At start-up the rule set is run against a document known to be clean. If a rule name is wrong, the checker refuses to start and says why, rather than reporting a phantom error on every page it ever sees. It is there because that happened once: one rule name that did not exist would have invented the same error sitewide.

Markup is one layer of one scan

The same run parses your stylesheets against the W3C property grammars, follows every link, expands your structured data and renders the page in a real browser. 986 rules in total, and each finding cites the standard it comes from. Valid markup tells you the document is well formed, not that the page works.

Questions

Is this the same as the W3C validator?

It checks the same specification - the HTML Living Standard - using an offline implementation of it. The W3C's own Nu Html Checker is the reference implementation; this produces the same class of finding, and reports line and column the same way.

Why does my page pass in the browser but fail here?

Because browsers are required to repair broken markup rather than refuse it. A nested anchor, an unclosed paragraph or a stray end tag all render without complaint - the parser fixes them and moves on. This validator reads the source before that repair happens, which is the only way to see them.

Does it check accessibility?

Not here. Accessibility is checked by the WCAG engine against the live rendered page in the Accessibility checker, plus a second engine (a second independent engine) for coverage. Keeping them separate is deliberate: running two engines' overlapping rules in one score would penalise the same defect twice.

HTML Validator

It renders fine. So how can the markup be wrong?

What it costs you when this is wrong

Two elements, one id, the wrong one updates

A form inside a form submits nothing

disabled="false" still disables the button

Why run it here

Errors ranked by what they break

The rule table is checked before your page

Markup is one layer of one scan

How to fix HTML validation errors

What happens when you run it

Enter your address

We render it like a visitor

You get findings you can act on

What runs this check

Questions

Also checks

Other checkers

Run the html validator now

HTML Validator

It renders fine. So how can the markup be wrong?

What it costs you when this is wrong

Two elements, one id, the wrong one updates

A form inside a form submits nothing

disabled="false" still disables the button

Why run it here

Errors ranked by what they break

The rule table is checked before your page

Markup is one layer of one scan

How to fix HTML validation errors

What happens when you run it

Enter your address

We render it like a visitor

You get findings you can act on

What runs this check

Questions

Also checks

Other checkers

Run the html validator now