What HTML validation checks

An HTML validator, sometimes called a conformance checker, examines markup against the syntax and structural requirements defined by web standards. It may report problems such as:

• an element appearing where it is not permitted;
• an unmatched or misplaced closing tag;
• an invalid or obsolete attribute;
• duplicate values where uniqueness is required;
• missing document-level information; or
• markup that cannot be interpreted according to the expected content model.

This makes validation a useful part of web standards quality assurance. It can reveal mistakes that are difficult to notice through visual inspection alone.

Validation does not determine whether a page is understandable, accessible, fast, secure, useful, or effective in search. A document made entirely from generic elements may be conforming while communicating very little structure. A valid form can still have unclear labels, and a valid interactive control can still be difficult to use with a keyboard.

A page displaying correctly is not proof of valid markup either. Browsers are designed to recover from many authoring mistakes. During parsing, a browser may implicitly close elements, move nodes, or otherwise construct a usable document from imperfect source code. Browser parsing fundamentals explain why successful rendering and markup conformance are related but distinct.

Choose what to validate

Before interpreting a report, identify exactly what the validator examined. A published URL, a complete HTML document, an editor fragment, and a browser’s live document are not necessarily the same artifact.

A published URL

Validating a public URL is often the most practical way to examine the complete HTML response delivered by a website. It includes markup supplied by the theme, templates, plugins, reusable components, and content management system—not only the article body visible in an editor.

Confirm that the URL represents the version you intend to review. A draft, preview, cached page, staging page, and public page may return different markup.

A complete HTML document

A complete document includes the document type, root html element, document metadata, and page body. This is usually the clearest input when reviewing a hand-written page or a saved response.

Readers who need additional structural background may find HTML document anatomy helpful.

An HTML fragment

A fragment may be appropriate when reviewing markup copied from a CMS editor, component, or template partial. Its interpretation can depend on the context in which it will eventually appear. A fragment that seems isolated in an editor may be nested inside elements supplied elsewhere by the publishing system.

When possible, validate the complete generated page after checking the fragment. This reveals relationships that are not visible when one section is examined alone.

The live browser document

The HTML initially returned by a server can differ from the live document after the browser parses it and JavaScript modifies it. Browser developer tools generally show the current Document Object Model, while a URL-based checker commonly evaluates the markup it retrieves.

Neither view should automatically replace the other. The source can reveal authoring and template problems; the live document can reveal what parsing and scripts produced.

A practical HTML validation workflow

The workflow is iterative. A correction may resolve several findings, expose a different problem, or show that the initial line of investigation was incomplete.

1. Identify the exact page and version

   Record the URL, environment, publication state, and time of the check when those details matter. Confirm whether you are reviewing production, staging, a preview, or local source.

2. Preserve the initial result

   Keep a copy or screenshot of the report, especially when several people maintain the site. The baseline makes it easier to determine what changed after a correction.

3. Understand the checker’s terminology

   Distinguish errors from warnings, informational notes, and advisory messages according to the tool’s own documentation. These labels describe different kinds of findings, but they do not provide a universal measure of user impact.

4. Read the finding in context

   Examine the cited markup and the elements immediately before and after it. Do not treat the message or line number as a complete diagnosis. The reported location may be where the checker could finally recognize a problem rather than where the mistake began.

5. Look for a shared underlying cause

   Several findings can result from one missing, misplaced, or incorrectly nested element. Investigate the earliest structurally relevant finding before editing every reported line independently.

6. Locate the responsible source layer

   Determine whether the markup comes from page content, a reusable block, a theme template, a plugin, a component, or a script. The visible output identifies the problem, but it may not identify where the durable correction belongs.

7. Make the smallest appropriate correction

   Correct the cause without restructuring unrelated parts of the page. A focused change is easier to review, test, and reverse if necessary.

8. Run validation again

   Rerun the same check against the same kind of input. Observe which findings disappeared, which remain, and whether any new findings appeared.

9. Check the page itself

   Review the affected content, structure, styling, and interactions. If the change affects navigation, forms, buttons, menus, dialogs, or other controls, include relevant keyboard and assistive-technology checks.

10. Document unresolved findings

    If a correction requires theme access, plugin changes, developer review, or additional investigation, record the finding, its likely source, the pages affected, and what has already been tested.

Example: one markup mistake can produce several findings

Consider a simplified content fragment containing an introductory paragraph followed by a list:

<p>
  The guide covers:
  <ul>
    <li>Document structure</li>
    <li>Form labels</li>
  </ul>
</p>

The intention is understandable, but a paragraph cannot contain a list in this way. When a browser encounters the opening ul element, its parser may implicitly close the paragraph. The final </p> can then appear to have no matching open paragraph.

Depending on the checker and submitted context, the report may identify both the invalid placement of the list and a later paragraph end-tag problem. Those findings are related. Adding or removing tags at the later location without understanding the nesting would address a symptom rather than the cause.

The intended structure can be written as separate sibling elements:

<p>The guide covers:</p>
<ul>
  <li>Document structure</li>
  <li>Form labels</li>
</ul>

A useful review would proceed as follows:

1. Confirm that the problematic fragment appears in the generated page.
2. Inspect the surrounding markup rather than only the final reported line.
3. Recognize the list inside the paragraph as the underlying structural cause.
4. Find whether the nesting was introduced by article content, a block, or a template.
5. Separate the paragraph and list at the appropriate source layer.
6. Validate the page again.
7. Confirm that the introductory text and list still display and read in the intended order.

This example also shows why validation findings should not always be treated as independent tasks. Correcting one cause may remove multiple messages from the next report.

How to prioritize validation findings

There is no universal severity ranking that applies equally to every website. Priority depends on the kind of problem, where it occurs, how widely it is repeated, and whether it affects meaning or interaction.

Useful questions include:

• Does the finding affect a form, navigation system, table, heading structure, or interactive control?
• Does it change how the browser constructs the document?
• Does it make relationships between elements unclear?
• Does the same problem appear on one page or across an entire template?
• Is there an observed effect on reading order, keyboard use, scripting, styling, or assistive technology?
• Is the cause understood well enough to make a safe correction?

A repeated template error may deserve attention before several isolated content mistakes because one correction could improve many pages. An isolated issue may still come first when it interferes with an important task or creates a clear barrier.

Conversely, a warning should not be dismissed merely because the page appears normal, and an error label should not lead to an untested change. The report supplies evidence; context supplies significance.

Finding the source of invalid HTML in WordPress or another CMS

In a content management system, the person reviewing a page may not control every part of its final markup. The generated document can combine several layers:

Page or article content

Paragraphs, headings, lists, images, embeds, and custom HTML entered for one page.

Reusable content

Shared blocks, patterns, widgets, shortcodes, and components used in several locations.

Templates and themes

Headers, footers, navigation, sidebars, layout containers, and other site-level structures.

Plugins and integrations

Forms, galleries, commerce interfaces, analytics elements, consent tools, and third-party embeds.

Client-side scripts

Markup inserted, removed, or reorganized after the initial document loads.

Use distinctive nearby text, class names, IDs, or component names to trace the output back to its source. If the same fragment appears on many pages, inspect shared components and templates before editing each page separately.

A content editor can often correct a malformed heading, list, link, or custom HTML block safely. Findings involving templates, plugin output, scripts, or unfamiliar interactive behavior may be better documented for a developer or site maintainer.

A useful handoff includes:

• the affected URL or template;
• the validation finding;
• the relevant markup excerpt;
• the suspected source layer;
• whether the issue is repeated;
• any observed effect on the page; and
• the changes or tests already attempted.

Verify more than the disappearance of a message

Rerunning the validator is necessary because it shows whether the checked conformance problem remains. It is not the final verification step.

After making a correction, review the area affected by the change:

• Does the content still appear in the intended order?
• Are headings, lists, tables, and landmarks still structurally meaningful?
• Did a styling rule depend on the previous markup?
• Do links, buttons, forms, and scripted controls still work?
• Can interactive elements still be reached and operated from a keyboard?
• Does the page behave consistently at different viewport sizes?
• Did the correction affect other pages using the same component or template?

For changes involving interactive controls, keyboard navigation testing is a natural continuation. For broader structural review, common semantic HTML mistakes can help identify problems that a conformance report alone may not fully explain.

The goal is not simply to make a message disappear. It is to leave the page’s markup, meaning, and behavior better understood.

HTML validation review checklist

• Confirm which URL, document, fragment, or environment was checked.
• Save the initial report when comparison or collaboration will be useful.
• Read each finding with its surrounding markup.
• Investigate whether several messages share one cause.
• Identify whether the source is content, a component, a template, a plugin, or a script.
• Make a focused correction at the appropriate layer.
• Run the same validation check again.
• Review the affected content, styling, structure, and behavior.
• Test relevant interactions beyond visual appearance.
• Document unresolved findings and their known context.

A reasonable stopping point is reached when the understood findings have been corrected or clearly documented, validation has been rerun, and the affected page has been checked in context. Other forms of review—accessibility, performance, compatibility, content quality, and functional testing—remain separate parts of caring for the webpage.

Frequently asked questions

Does valid HTML make a webpage accessible?

No. Conforming markup can provide a stronger structural foundation, but accessibility also depends on semantics, labels, keyboard behavior, visual presentation, content clarity, and compatibility with assistive technologies. Validation supports accessibility work; it does not replace it.

Why does a validator report a problem on a line that looks correct?

The reported line may be where the checker recognized the consequences of an earlier mistake. Missing end tags, invalid nesting, and parser recovery can cause a later element to be reported even when the underlying cause appears earlier in the document.

Should every validation warning be fixed?

Every finding should be understood in context, but not every advisory message requires the same response. Consult the checker’s explanation, inspect the markup, consider the page’s intended behavior, and document the reason when a finding remains unresolved.

Why does the HTML in browser developer tools differ from the page source?

Page source usually represents the HTML response, while developer tools commonly show the DOM after browser parsing and possible script changes. The browser may repair malformed structures during parsing, and JavaScript may add or reorganize elements after loading.