How to Use the Html Validator: Step-by-Step Tutorial

The Html Validator checks your HTML files entirely in the browser — your file is never uploaded, nothing leaves your machine, and no account is required. This tutorial walks through every step: loading a file, reading each result panel, understanding what each finding means, and fixing the most common issues designers and developers encounter in HTML files.

Connect on LinkedIn →

Step 1 — Open the Tool

Navigate to /developer-tools/html-validator/. The tool loads entirely in the browser using standard Web APIs. There are no cookies, no account, and after the initial page load, no network requests are made during validation. You can confirm this in your browser's DevTools Network panel — validating a file generates zero outbound requests.

You can reach the tool from the Developer Tools hub, the command palette (press Ctrl+K or ⌘K and type "Html Validator"), or directly via the URL above.

Step 2 — Load Your HTML File

The tool accepts .html and .htm files. There are two ways to load a file:

Option A — Drag and drop. Drag your HTML file from your file manager and drop it onto the dashed drop zone in the centre of the tool. A full-screen drop overlay appears when you drag over the browser window, with the message "Drop your HTML file anywhere — Release to validate." You can drop anywhere on the page, not just on the drop zone itself.

Option B — Browse. Click the "browse" link inside the drop zone to open your operating system's file picker. Select your .html or .htm file and confirm. The file loads immediately.

Once a file is loaded, the filename appears below the drop zone with a clear button (×) you can click to remove the file and start over. If you drop a file with an unsupported extension, a red error message appears explaining the issue — only .html and .htm files are accepted.

Step 3 — Run Validation

After loading a file, click the blue "Validate HTML" button. Validation is not automatic — you must click this button to run the checks. This is intentional: it gives you a chance to load the right file before running analysis, which can be important for larger HTML documents.

To remove the current file and start with a different one, click the grey "Clear" button. This resets the tool completely, clearing all results and returning to the initial drop zone state.

Step 4 — Read the Status Bar

After clicking Validate HTML, a status bar appears immediately below the buttons. It shows one of three states:

• Green — HTML Parsed Successfully. No structural errors were found. There may still be warnings — check the panels below.
• Red — Validation errors found. The document has one or more structural or required-element problems that should be fixed. The count of errors is shown in the status bar.
• Yellow — Warnings or hints found. No errors, but the validator found issues worth reviewing — deprecated elements, accessibility gaps, or missing recommended attributes.

The status bar is a quick summary. Always scroll down to read the detailed result panels, which explain every finding individually.

Step 5 — Review the Results Panels

Below the status bar, up to four panels appear depending on what the validator found:

Validation Errors panel (red)

Lists every structural error found — problems with DOCTYPE, missing required elements, tag nesting violations, or other issues that constitute invalid HTML. Each item explains what is wrong and what to fix. Errors appear first because they represent the most impactful problems to resolve.

Warnings & Best-Practice Hints panel (yellow)

Lists non-fatal issues — deprecated elements still present in the document, accessibility hints (such as missing alt attributes or form labels), and missing recommended attributes. Each item includes a brief explanation. Warnings are worth reading even if you don't act on every one; some may be intentional (e.g., deprecated presentational attributes kept for email client compatibility).

HTML Parsed Successfully panel (green)

Appears when the document parsed without structural errors. Shows a small stats grid with document metrics: total element count, unique tag count, whether a <title> element is present, whether a lang attribute is present, and whether a <meta charset> declaration was found. This panel is informational — it tells you the document is structurally sound.

Document Info panel

A detail table showing key document properties extracted from the parse: the declared character encoding, the document language (from the lang attribute on <html>), the page title, and the meta description if present. This is useful for quickly confirming that your SEO metadata is in place and correctly formed.

Step 6 — Understand Each Finding

Here is what the most common findings mean and how to respond to them:

Missing or invalid DOCTYPE

Example message: "Missing DOCTYPE declaration. Add <!DOCTYPE html> as the first line."

The DOCTYPE declaration was absent or not the first content in the file. Fix: add <!DOCTYPE html> as the very first line, before any whitespace, comments, or other content. Do not place a comment above it — even a comment before the DOCTYPE triggers quirks mode in some browsers.

Missing required structure element

Example message: "Missing <title> element inside <head>. A page title is required."

A required structural element — such as <html>, <head>, <body>, or <title> — is absent. Fix: add the missing element in the correct location in the document hierarchy. If you are working with an HTML snippet (not a full document), this is expected — snippets intentionally omit the document shell.

Missing <meta charset>

Example message: "No <meta charset> declaration found."

The document has no character encoding declaration. Fix: add <meta charset="UTF-8"> as the first element inside <head>. It must appear within the first 1024 bytes of the document to be effective.

Deprecated element detected

Example message: "Deprecated element <font> found. Use CSS for styling instead."

An element that was removed from the HTML5 specification is present. Common deprecated elements include <font>, <center>, <marquee>, <blink>, and <strike>. Fix: replace with the CSS equivalent. For <font>, use a <span> with inline styles or a CSS class. For <center>, use text-align: center or flexbox. Note: if you are writing email HTML, some deprecated presentational attributes may be required for email client compatibility — in that case, treat this as a warning you are intentionally ignoring.

Missing alt attribute on image

Example message: "Image missing alt attribute: <img src='hero.jpg'>."

An <img> element has no alt attribute. Fix: add alt="description of image" for informative images, or alt="" for decorative images that screen readers should skip. Never omit the attribute entirely — that is always incorrect.

Missing form label

Example message: "Input element has no associated label."

A form control (<input>, <select>, or <textarea>) has no associated <label> element. Fix: either wrap the input in a <label> element, or use a <label for="id"> that references the input's id attribute. Placeholder text is not a substitute for a label.

Missing lang attribute on html element

Example message: "The <html> element is missing a lang attribute."

The document's primary language is not declared. Fix: add lang="en" (or the appropriate language code) to the opening <html> tag: <html lang="en">. This helps screen readers use the correct pronunciation rules and assists search engines in language targeting.

Unclosed or improperly nested tags

Example message: "Possible unclosed or improperly nested tags detected."

The document structure suggests a tag was opened but not properly closed, or elements are nested in a way that conflicts with HTML rules. Fix: check the element structure carefully around the area described. Use a code editor with HTML syntax highlighting to spot mismatched open/close pairs. Common causes: a missing </div>, a <p> inside an <a> (invalid in HTML5), or a block element inside an inline element.

Step 7 — Fix and Re-Validate

After reviewing the results, fix the issues in your source file and re-validate. The most efficient workflow:

1. Note all errors before closing the results panel or switching files.
2. Open your HTML file in a code editor with syntax highlighting (VS Code, Sublime Text, Notepad++, or similar).
3. Address errors first, starting from the top of the document — a missing DOCTYPE or unclosed tag near the top can affect everything below it.
4. Then address warnings, deciding for each whether it applies to your context (e.g., is this a web page or email template?).
5. Save the file, then drag it back onto the tool (or use the browse link after clicking Clear) and click Validate HTML again.
6. Repeat until the status bar is green and the warnings panel is empty or contains only intentional exceptions.

Worked Examples

Example 1: Template exported from a design tool with missing document structure

A Figma-to-HTML export produces a file that starts directly with a <div> — no DOCTYPE, no <html>, no <head>, no <title>. The validator reports four errors. Fix: wrap the export in the correct document shell:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Page Title</title>
</head>
<body>
  <!-- your exported HTML here -->
</body>
</html>

Re-validate after adding the shell — the four structural errors should disappear, leaving only any deprecated-element or accessibility warnings from the export content itself.

Example 2: Images without alt attributes across a design template

A landing page template has 8 <img> elements, none with alt attributes. The validator reports 8 accessibility warnings. Go through each image:

• Hero image (meaningful): alt="Woman reviewing analytics dashboard on laptop"
• Decorative divider line (decorative): alt=""
• Product screenshot: alt="Screenshot of the reporting interface showing monthly revenue chart"
• Client logo (linked): alt="Acme Corp logo"

After adding appropriate alt attributes to all 8 images, re-validate. The accessibility warnings section should now be empty.

Example 3: Deprecated <font> tags in a legacy email template

An email template uses <font face="Arial" size="3" color="#333"> for text styling. The validator flags these as deprecated. For email HTML targeting Outlook, <font> elements are sometimes retained for compatibility. If you need to keep them, note the warning as intentional. If you can modernise the template, replace each occurrence with an inline-styled <span>:

<!-- Before -->
<font face="Arial" size="3" color="#333333">Body text here</font>

<!-- After -->
<span style="font-family: Arial, sans-serif; font-size: 14px; color: #333333;">Body text here</span>

Example 4: Form inputs without labels in a contact form

A contact form has three <input> elements (name, email, message textarea) with placeholders but no <label> elements. The validator reports three accessibility warnings. Add labels using the for/id pattern:

<!-- Before -->
<input type="text" placeholder="Your name">

<!-- After -->
<label for="name">Your name</label>
<input type="text" id="name" placeholder="Your name">

Apply the same pattern to the email input and the textarea. Re-validate to confirm all three warnings resolve.

Tips and Edge Cases

• HTML snippets vs. full documents. The validator expects a complete HTML document. If you validate a snippet (a partial block of HTML without the document shell), you will always see errors for missing DOCTYPE, missing <html>, and missing <head>. This is expected. For snippet validation, you can temporarily wrap the snippet in the minimal document shell shown in Example 1, validate, then unwrap it.
• Email HTML. Email HTML has different constraints than web HTML. Deprecated elements and inline styles that would normally be flagged as warnings may be intentional for email client compatibility. Use the validator to identify issues, then decide case-by-case based on your target email clients.
• Large files. The tool reads files using the browser's FileReader API and runs all checks in JavaScript. Files up to several hundred kilobytes validate quickly. Very large generated HTML files (5 MB+) may take a moment to parse.
• CMS-generated HTML. If you export HTML from a CMS or email builder and validate the output, you may find deprecated elements or missing attributes introduced by the tool rather than by your template. Document these as known issues from the build system and report them to your tool vendor if they affect production quality.
• Accessibility warnings are not errors. The validator separates errors (structural problems) from warnings (accessibility and best-practice hints). A document can have zero errors and still need work on accessibility. Review warnings even on a green-status document.
• Privacy. The tool reads your file using the browser's FileReader API. Your HTML bytes are processed in-memory by JavaScript running in your browser tab. Nothing is sent to any server at any point. You can verify this in your browser's DevTools Network panel — no requests appear during or after validation.