Free · Fast · Privacy-first

Validate HTML5 Online

HTML5 reshaped the specification in three directions at once: it added new semantic elements, removed presentational ones, and relaxed several XHTML-era syntax rules.

⚡

Validates against the HTML5 specification

🔒

Flags deprecated HTML4 patterns

✨

Checks new HTML5 element usage

⚡

Free with no sign-up

Cost: Free forever
Sign-up: Not required
Processing: In your browser
Privacy: Files stay local

FreeNo signupWhite-label

Add this HTML Validator to your website

Drop the HTML Validator into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.

Files stay 100% in the visitor's browser
Responsive — adapts to any container width
Free forever, no API key needed

Embed code

<iframe
  src="https://www.fixtools.io/html/html-validator?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="HTML Validator by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

<iframe
  src="https://www.fixtools.io/html/html-validator?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="HTML Validator by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.

What Actually Changed in HTML5: New Rules, Removed Elements, and Relaxed Syntax

HTML5 (now the HTML Living Standard) made three categories of changes from HTML 4.01 and XHTML 1.0. First, it added new semantic elements: header, footer, main, nav, aside, article, section, figure, figcaption, time, mark, and others. These elements carry meaning that div and span do not, and using them correctly provides ARIA landmark roles and document outline information automatically. Second, it removed or deprecated a significant set of presentational and frame-related elements: font, center, big, strike, tt, frame, frameset, and noframes were removed. Using these triggers validation errors because they are not part of the current spec at all.

Third, HTML5 relaxed several XHTML syntax requirements. Attribute values do not need to be quoted if they contain no whitespace or certain special characters. Self-closing slash notation on void elements (like br/, img/) is permitted but not required. Tags and attribute names are case-insensitive. The boolean attribute syntax (writing required instead of required="required") is correct. These relaxations mean HTML5 documents can be written more concisely, but they also mean developers migrating from XHTML may write patterns that are valid but unfamiliar to XHTML linters, leading to mismatched expectations during code review.

The <!DOCTYPE html> declaration in HTML5 is not a real DOCTYPE in the SGML sense; it is a short string that tells browsers to use the standards mode parser rather than quirks mode. It carries no reference to a DTD file because HTML5 is not SGML. Validators that rely on DTD files (like the older W3C validator modes) cannot validate HTML5 correctly. The Nu HTML Checker, deployed by W3C in 2013, was built specifically to validate the HTML5 spec without DTD dependency, and it is the reference implementation for accurate HTML5 validation against the current Living Standard.

A fourth change worth highlighting is the move from versioned releases to a Living Standard model. Earlier HTML revisions were frozen documents tied to specific years and version numbers; today the spec is updated continuously to reflect what browsers actually implement. This means HTML5 validation is a moving target in the sense that new rules can appear over time, but it also means the validator output always reflects the spec that browsers are currently shipping. Treating the Living Standard as the canonical reference is the most practical approach for any HTML written today.

WHATWG HTML Living Standard MDN, HTML5 element list W3C Nu HTML Checker

How to use this tool

💡

Paste your HTML5 code and validate. The tool checks for correct use of HTML5 elements, attributes, and patterns.

How It Works

Step-by-step guide to validate html5 online:

1
Add the HTML5 doctype
Confirm your HTML starts with <!DOCTYPE html> before validating. The doctype must be the very first content in the file with no preceding whitespace or byte-order mark. A missing or malformed doctype puts browsers into quirks mode and produces a class of layout differences that have nothing to do with anything else in the document.
2
Paste your HTML5
Paste the complete HTML5 document or component into the validator input panel. The validator accepts any length and parses the entire content as soon as it is pasted, so there is no need to wait for a load step or to upload a file. Both fragments and full documents are supported, and each provides different signals about the document health.
3
Validate
Click Validate to run the check against the HTML Living Standard. The validator records every deviation from the current spec, including deprecated elements, invalid attribute values, missing required attributes, and structural rule violations. Results appear within seconds in a structured panel ready for the fix loop to begin.
4
Fix deprecated patterns
Replace any flagged deprecated HTML4 elements or attributes with their HTML5 equivalents. Common substitutions include CSS rules in place of font and center elements, table-based layout replaced with CSS layout, and presentational attributes such as bgcolor and align replaced with corresponding CSS declarations. Each fix moves the document closer to clean conformance with the current spec.

Real-world examples

Common situations where this approach makes a real difference:

Migrating an HTML4 site to HTML5

Run every page through the HTML5 validator to identify deprecated elements, font-based and table-based layout patterns, and missing HTML5 doctype declarations. The validator turns a vague migration goal into a concrete list of changes for each template, which can be triaged by impact and assigned to the team. Once the structural deprecations are resolved, the same validator becomes a regression guard that prevents anyone from accidentally reintroducing the old patterns later.

Ensuring a new project is HTML5-compliant

For new projects targeting modern browsers, validate all HTML5 code as it is written to confirm correct use of new semantic elements and current attribute syntax. Catching mistakes during development is dramatically cheaper than retrofitting compliance later, and the habit also reinforces good semantic instincts in developers who are still learning which element to reach for. The validator becomes a coaching tool as well as a quality gate.

When to use this guide

Use this when migrating legacy HTML to HTML5 or when building HTML5-first projects that need to avoid deprecated elements and patterns.

Pro tips

Get better results with these expert suggestions:

Understand which HTML5 elements replaced older patterns

HTML5 introduced semantic elements (<article>, <section>, <nav>, <header>, <footer>, <main>, <aside>) that replace generic <div> layouts. Using the old div+class pattern is not a validation error but is flagged as a missed semantic opportunity. Gradually replacing layout divs with semantic elements improves both accessibility and SEO.

Test for HTML5 doctype declaration first

The HTML5 doctype <!DOCTYPE html> must be the very first line of your document, before any whitespace or BOM markers. An incorrect or missing doctype causes browsers to enter quirks mode, which applies different layout rules. Validate that your doctype is correct before investigating any other HTML5 compliance issues.

Custom HTML5 data attributes must follow naming rules

HTML5 data-* attributes must: start with data-, contain at least one character after the hyphen, use only lowercase letters and hyphens (no uppercase, no spaces), and not start with xml. Attributes like data-ID or data-myProp are not valid HTML5. The validator will flag these.

Validate ARIA roles alongside HTML5 semantics

HTML5 validation and ARIA validation are related but separate. An HTML5-valid element can still have an invalid ARIA role (for example role='button' on a <div> is valid HTML5 but semantically incorrect when the element is not interactive). Use an accessibility checker alongside the HTML5 validator for complete semantic validation.

Always declare the HTML5 doctype

Every HTML5 document must start with <!DOCTYPE html>. Without it, browsers enter quirks mode and may render your page differently from modern standards.

Replace deprecated elements

HTML5 removed elements like <font>, <center>, <marquee>, and <frame>. Validation will flag these. Replace them with CSS equivalents.

Use semantic HTML5 elements

HTML5 introduced <header>, <nav>, <main>, <article>, <section>, <aside>, and <footer>. Use these instead of <div> where semantically appropriate. HTML5 validation enforces the current living standard rather than legacy doctypes. New elements like article, section, nav, and aside must be used semantically; new form input types like email, tel, and url must be applied to fields where they make sense; new attributes like required, pattern, and autocomplete must be syntactically correct. Our HTML5 validator catches misuse of these modern features that a legacy validator would silently allow. This matters because HTML5 features tie directly into browser behaviour and accessibility-tool interpretation, where errors degrade the user experience even when the page renders. Modern browsers enforce HTML5 rules at the parser level, which means invalid markup can produce surprising rendering outcomes. Self-closing slashes on void elements like img and br are tolerated but ignored. Unclosed paragraphs auto-close at the next block-level element. Mismatched table structures get reorganized into the next valid layout. Knowing what the browser will silently fix versus what it will surface as a visible bug requires running your markup through a validator that mirrors browser parsing behavior. Our HTML5 validator does exactly that, so you see the same warnings the browser would emit in its DevTools console.

FAQ

Frequently asked questions

HTML5 validation checks for correct use of new semantic elements, removed deprecated elements, and updated attribute rules. HTML4 validation used an older, stricter DTD-based specification tied to a specific version document. The Nu HTML Checker that drives modern HTML5 validation walks the document with the same parser model browsers use, while older DTD-based tools compared the document against a frozen rule file. For any HTML written today, HTML5 (Living Standard) validation is the right reference because that is what browsers actually implement.

Use <!DOCTYPE html>: it is the standard HTML5 doctype. The declaration tells browsers and validators to use the HTML5 parsing rules, which are more lenient than the strict XHTML rules of earlier standards. It must be the very first content in the file, with no whitespace, BOM, or characters before it. Missing or malformed doctype declarations push the browser into quirks mode and produce a class of layout differences that have nothing to do with anything else in the document.

Elements removed in HTML5 include font, center, big, strike, tt, frame, frameset, noframes, acronym, applet, and dir. Using any of these triggers a validation error because they are not part of the modern spec at all. Replace them with semantic elements where appropriate (for example aside or footer for sidebar content), with CSS for presentational concerns previously expressed by font and center, and with iframe in place of the entire frame model that HTML5 specifically retired.

No. HTML5 has optional closing tags for certain elements, including li, dt, dd, p, and others. Void elements like br, img, input, and link never have closing tags. The spec defines precisely which closing tags are optional and which are mandatory. While the relaxed rules can make documents shorter, many teams still write all optional closing tags explicitly because it removes any ambiguity about where an element ends and improves the readability of complex nested structures.

The HTML Living Standard is the current version of the HTML spec, maintained by WHATWG. It supersedes the versioned HTML5 documents that used to be published by W3C. HTML5 is often used colloquially to mean the current modern HTML spec, but technically the Living Standard is the canonical reference. In 2019 W3C agreed to recognise the WHATWG Living Standard as the single authoritative source for HTML, which removed the long-running confusion about which document developers should follow.

Most HTML5 semantic elements (header, main, nav, etc.) are supported in all browsers released after 2012. For Internet Explorer 8 and earlier, a JavaScript shim known as html5shiv was required to make the elements styleable. Modern development can use semantic elements without compatibility concerns because the browsers that needed the shim are no longer maintained by their vendors and have effectively zero market share on most sites.

Yes. HTML5 introduced new input type values including email, url, number, range, date, time, color, search, and tel. Using an invalid or misspelled type value is a validation error. Browsers fall back to type="text" for unrecognised values, which is why such errors are easy to miss without validation: the form appears to work, but the intended type-specific behaviour (validation, keyboard, picker UI) is silently absent until you catch the typo with the validator.

The HTML5 validator checks semantic element usage (correct nesting of article within section, for example), ARIA role validity, new attribute constraints (pattern and required on input), polyglot HTML requirements, and the prohibition of deprecated elements. These were not checkable with the DTD-based validators used for HTML 4.01 because the rules depended on parser-level information that DTDs cannot represent. Modern validators are essentially miniature parsers that apply spec rules during the walk rather than after the fact.

Yes. HTML5 data attributes must start with data-, followed by at least one character that is a lowercase ASCII letter, digit, or hyphen. They must not contain uppercase letters or colons, and they must not start with xml in any combination of case. Custom data attributes that violate these naming rules are flagged as validation errors, so a habit of using lowercase, hyphen-separated names from the start prevents the entire category of issues without any additional thought. HTML5 introduced new semantic elements (article, section, nav, aside, header, footer) and changed the rules around several existing elements. Validating against the HTML5 specification specifically ensures your markup uses these new elements correctly and avoids legacy patterns that worked in HTML4 but now produce warnings. Modern frameworks like React, Vue, and Next.js output HTML5 by default, but custom server-side rendered output sometimes mixes older patterns that an HTML5-specific validator will catch immediately. HTML5-specific validation also surfaces newer best practices like proper use of figure/figcaption pairs, dialog elements, and the picture element for responsive images. HTML5 also introduced richer semantics for content authoring: time elements for dates, mark elements for highlighting, and meter elements for gauges. Some teams maintain a private validator instance configured with their specific organizational HTML conventions. Teams without dedicated DevOps capacity can achieve a similar outcome by combining the standard W3C check with a small linting layer for organization-specific rules using widely available open-source tools that integrate easily with existing CI workflows.

Yes, modern HTML5 validators understand the custom element specification and validate proper definition and usage. They check that custom element names contain a hyphen (required by spec), that template tags are used correctly for shadow DOM patterns, and that slot attributes are wired correctly. For modern frameworks like React 19 and Vue 3, framework-aware validators understand JSX and template syntax distinctions automatically.