HTML Validator
Check HTML against the official W3C Nu validator and see every error in context: line and column, the exact offending markup with the failing range highlighted, and a jump-to-line source view. Paste, upload, or load a URL.
HTML Input
Your markup is sent to the W3C. Validation is performed by the official W3C Nu validator, so your HTML leaves your device. We don't store or log it, but please don't paste credentials, API keys, or unpublished content.
Formatting runs in your browser and changes line numbers — validate again afterwards so the reported positions match.
Validation Results
Enter HTML and press "Validate HTML" to see W3C results.
Sample HTML Code
About HTML Validator
An HTML validation front-end for the official W3C Nu validator. Paste markup, upload a file, or load a public URL, and every message comes back with its line and column, the W3C's own context extract, and the failing character range highlighted with a caret so you can see exactly which attribute or tag triggered it. A jump-to-line control scrolls a windowed source view straight to the offending line, and a separate local structure scan (DOCTYPE, html/head/body, title) runs in your browser so you can tell at a glance which findings came from the W3C and which are our own heuristics. Validation is performed by the official W3C Nu validator: your markup is sent to our server and forwarded to validator.w3.org, then the results are returned to you. We don't store or log your markup, but it does leave your device — so don't paste HTML containing credentials, API keys, or unpublished content you can't share with a third party.
Problems We Solve
- W3C error messages that give you a line number but no idea which attribute or tag on that line is actually wrong
- Validators that dump hundreds of messages with no way to filter errors from warnings and informational notes
- Browser rendering inconsistencies caused by unclosed tags and invalid nesting that browsers silently patch differently
- Duplicate IDs, stray end tags, and invalid attribute values that break JavaScript selectors and CSS in production
- Validation failures that are actually service problems — rate limits or W3C downtime — being misreported as markup errors
- Losing your place in a long document when you have to scroll manually to line 4,812
- Accessibility basics (missing alt text, unlabelled form controls, skipped heading levels) going unnoticed in a code review
- Uncertainty about whether an online validator keeps a copy of the markup you paste into it
Why use a HTML Validator?
Valid HTML renders consistently across browsers because the browser never has to guess how to repair your markup — and different engines guess differently. Invalid nesting silently reshapes the DOM, which is how a stray end tag ends up breaking a querySelector or a CSS descendant rule in production and nowhere else. This tool uses the same W3C Nu engine as validator.w3.org, but shows each message with the offending source range highlighted, a caret under the exact characters, severity filters, and a jump-to-line source panel, so fixing a 200-message document is a short pass rather than an afternoon. Transport failures are reported as transport failures, never disguised as markup errors.
Who is it for?
Frontend developers debugging markup that renders differently across browsers. Template and CMS authors checking generated output rather than source templates. QA engineers adding a validation gate before release. Agencies and freelancers proving standards compliance on client deliverables. Email developers checking template markup before testing in real clients. Accessibility practitioners using structural validity as the baseline before a real WCAG audit. Educators and learners who want to see exactly which characters a validator objects to, not just a line number.
How to use the tool
Choose an input method: paste markup, upload an .html/.htm file (up to 5 MB), or load a public URL (up to 1 MB, the server-side fetch proxy's cap).
Read the notice about markup being forwarded to the W3C — the first paste waits for you to press Validate instead of submitting automatically.
Press 'Validate HTML'. Your markup is sent to the W3C Nu validator and the results come back with line and column numbers.
Use the error / warning / info chips to filter the message list down to the severities you're working on.
Read each message's source extract: the offending characters are highlighted and marked with a caret so you can see what the W3C objected to.
Press 'Jump' on any message to scroll the source panel to that line, which stays highlighted in the panel's colour for its severity.
Fix the markup in the editor — it stays visible next to the results — then press 'Validate again'; a dirty marker warns when the results are older than your edits.
Optionally press 'Format' to re-indent the document in your browser, then validate again so the reported line numbers match the new layout.
Copy the report as plain text or JSON to paste into a ticket, a code review, or a CI artefact.
Key Features
Official W3C Nu validation
Messages come from validator.w3.org's Nu engine — the same checker behind the official W3C service — covering HTML5, XHTML, and legacy doctypes, not a home-grown parser.
Line-level error context with highlighted extracts
Each message shows the W3C's own context extract with the failing character range highlighted and a caret underneath, plus line and column, so you can see the offending attribute or tag itself.
Jump-to-line source panel
A windowed source view renders 150 lines either side of the line you jumped to, so even a multi-megabyte document navigates instantly instead of freezing the tab.
Severity filters and exportable reports
Toggle errors, warnings, and informational messages independently in every input mode, then copy the filtered report as plain text or structured JSON.
Separate local structure scan
DOCTYPE, html/head/body and title presence are scanned in your browser from the raw source — labelled 'local' so it's never confused with the W3C verdict.
Honest transport error handling
Rate limits show a countdown and a retry button, W3C downtime says so explicitly, and oversize payloads name the limit. A failed request never invents a validation result and never discards your previous one.
Common Use Cases
Pre-deployment quality gate
Scenario: Validate rendered output before shipping, so unclosed tags and duplicate IDs are caught before they reshape the DOM in production.
✓ Catch structural defects while they're still cheap to fix.
Debugging a selector that works locally but not in production
Scenario: Invalid nesting makes the browser relocate elements, which silently breaks descendant CSS rules and querySelector calls. Validation reveals the repair the browser performed.
✓ Find the real cause instead of patching the symptom.
Auditing CMS or template output
Scenario: Load the public URL of a generated page and validate the HTML the server actually sends, rather than the template you wrote.
✓ See what the crawler and the browser really receive.
Client deliverable verification
Scenario: Run validation before handover and copy the JSON report into the delivery notes as evidence of standards compliance.
✓ Document code quality with a reproducible artefact.
Modernising legacy markup
Scenario: Validate old pages to surface obsolete elements and attributes, using the highlighted extracts to locate each one precisely.
✓ Work through a legacy codebase methodically.
Teaching and learning HTML
Scenario: Load a deliberately broken sample and watch the caret point at the exact characters the validator objects to.
✓ Learn the rules from the errors, not from guesswork.
Why Choose This Tool
- Uses the official W3C Nu engine rather than an approximate in-house parser
- Shows the failing character range from each W3C extract, highlighted and carets-marked
- Windowed source panel keeps multi-megabyte documents responsive
- Distinguishes rate limits, W3C downtime, and payload errors instead of reporting them all as invalid HTML
- States plainly that markup is forwarded to a third party, and waits for your first explicit Validate before auto-submitting
- No registration, no account, no paywall
Frequently Asked Questions
How do I validate HTML code with this tool?
Pick an input method: paste your markup, upload an .html/.htm file up to 5 MB, or enter a public URL (URL mode is capped at 1 MB by the server-side fetch proxy). Press 'Validate HTML' and the markup goes to the official W3C Nu validator. Results return as a list of messages with severity, line, column, and the W3C's own source extract with the offending characters highlighted. Use the error/warning/info chips to filter, press 'Jump' to scroll the source panel to any line, fix the markup in the editor — which stays on screen — and press 'Validate again'.
What's the difference between a W3C error, a warning, and an info message?
Errors are violations of the HTML specification: stray end tags, duplicate IDs, elements in places the content model forbids, invalid attribute values. Browsers recover from them, but each browser recovers its own way, so errors are where cross-browser bugs come from. Warnings flag markup that is technically conforming but risky or obsolete in practice — an empty heading, a section with no heading, a legacy doctype. Info messages are advisory, often about the parse mode or the character encoding the validator inferred. Fix every error; triage warnings against your project's standards; read info messages once for context.
Is my HTML private, and where exactly does it get sent?
It is not validated in your browser. When you press Validate, the markup is posted to the Toolsana API, which forwards it to validator.w3.org's Nu service and returns the response. We don't store or log the markup, but it does leave your device and reach a third party, so never paste credentials, API keys, internal URLs, or unpublished content you can't share. The first paste in a new browser deliberately waits for you to press Validate rather than auto-submitting. For fully offline checking, run the Nu validator locally (`vnu.jar`, or the `html-validate` npm package) instead.
Is this the same as validator.w3.org, and when should I use each?
The verdict is the same — both run the W3C Nu checker, so messages and line numbers match. The difference is the workflow around them. Here you get severity filters, the failing character range highlighted with a caret under each extract, a jump-to-line source panel that stays responsive on large documents, an editor that stays open for edit-and-revalidate cycles, and text or JSON report export. Use validator.w3.org when you want the canonical page to cite or its 'show source' and outline views; use this when you're actually working through a list of errors.
Why does my page look fine in every browser but still fail validation?
Because HTML parsing is defined to be error-tolerant. When a browser meets a stray `</span>` or a `<div>` inside a `<p>`, it doesn't stop — it applies the spec's recovery rules and builds whatever DOM it can. Looking correct only means the recovery happened to produce something acceptable. The risk is that recovery moves elements: a `<div>` inside a `<p>` implicitly closes the paragraph, so your CSS descendant rule and your `querySelector` now target a different tree than you wrote. Validation shows you the repair before it costs you a debugging session.
Can I validate HTML generated by React, Vue, or Next.js?
Yes, but validate the output, not the components. Two options. For a server-rendered page, load the URL here — the fetch proxy returns exactly what the server sends, which is what the crawler sees, but it does not execute JavaScript. For a client-rendered view, open DevTools, right-click the `<html>` element in the Elements panel, choose 'Copy outerHTML', and paste that. It includes framework-injected attributes such as React's hydration markers, so expect a few messages that come from the framework rather than from your own markup.
Does this tool check WCAG accessibility compliance?
No, and no HTML validator does. The W3C Nu checker enforces the HTML specification, which overlaps accessibility only where the spec itself requires it — `alt` on `<img>`, valid ARIA attribute names, correct table structure. This page adds four local heuristics on top, labelled as local: a missing `lang` on `<html>`, images with no `alt`, form controls with no label or `aria-label`, and skipped heading levels. Those are useful pre-checks, not an audit. Real WCAG 2.2 conformance needs axe DevTools or Lighthouse plus manual keyboard, focus-order, and contrast testing.
What are the size limits, and what happens if validation is rate limited or the W3C is down?
Pasted and uploaded documents are capped at 5 MB, matching the API's own limit; URL mode is capped at 1 MB because the server-side fetch proxy stops there. Transport problems are shown as transport problems, never as markup errors: a rate limit shows a countdown and a retry button, W3C downtime says the service is unavailable, and an oversize payload names the limit — and in every case your previous results stay on screen untouched. For the neighbouring checks, see the CSS Validator, JSON Validator, and HTML Formatter.
Technical Specifications
Supported Formats
- ✓HTML5 (including SVG and MathML embedded in HTML), XHTML 1.0/1.1, and legacy HTML 4.01 doctypes
- ✓W3C Nu validator messages with line, column, source extract, and highlight range
- ✓Input by paste, .html/.htm/.xhtml file upload, or public URL via the SSRF-guarded fetch proxy
- ✓UTF-8 source; leading BOM, XML prologs, and comments are skipped when detecting the DOCTYPE
- ✓Local structure scan for DOCTYPE, <html>, <head>, <body>, and <title> presence
- ✓Local heuristics for lang, image alt text, form labels, heading order, meta description, viewport, and charset
- ✓Report export as plain text or JSON, honouring the active severity filters
Limits & Performance
- •File Size: 5 MB pasted or uploaded; 1 MB when loading by URL
- •Validations: One W3C Nu round trip per validation, subject to API rate limiting
- •Response Time: Typically 1–3 s, dominated by the round trip to validator.w3.org
- •Browsers: Any modern browser; the source panel windows to 301 lines at a time
Pro Tips
- Fix errors from the top down — one unclosed element commonly produces a cascade of later messages that disappear together.
- Read the caret line, not just the message: it points at the exact characters the validator rejected.
- Turn off warnings and info with the chips when you're triaging a large document, then turn them back on for the final pass.
- Format before you validate, not after — formatting changes line numbers, and the dirty marker will warn you when the results are stale.
- URL mode returns the server's HTML, so a JavaScript-rendered app needs the DevTools 'Copy outerHTML' route instead.
- Validate the generated output of your CMS or framework, not the template source, since that's what browsers and crawlers actually parse.
- Duplicate IDs are reported as errors for a reason: `getElementById` and `#id` selectors silently resolve to the first match only.
- Treat a clean validation as the baseline, then run an accessibility audit — valid markup is necessary for assistive technology, not sufficient.
Share This Tool
Found this tool helpful? Share it with others who might benefit from it!
💡 Help others discover useful tools! Sharing helps us keep these tools free and accessible to everyone.