How this tool works
Parses pasted HTML and checks a small set of document, image, link, form-label, and duplicate-ID patterns.
How to use it
- Paste the relevant HTML.
- Review the detected counts and flagged patterns.
- Validate the final rendered page with appropriate specialist tools.
Limits to keep in mind
Browser parsing may repair malformed markup. The checks are not exhaustive and cannot assess visual accessibility or all HTML conformance rules.
Frequently asked questions
Does this certify valid HTML?
No. It only runs a limited set of structural checks.
Does it inspect a live URL?
No. Only pasted markup is analyzed.
What kinds of problems does it flag?
A small set of common ones, such as a missing document language, images without alt text, form fields without labels and duplicate IDs.
Is a clean result the same as valid or accessible HTML?
No. It is a quick screening, not a validator or accessibility audit. Use dedicated validators and manual testing for full coverage.
Scope of the structural review
The HTML Structure Checker is a quick screening tool for pasted markup. It parses the HTML in your browser and looks for a small set of common patterns that affect how a page is understood and used: document-level elements, images, links, form labels and duplicate identifiers.
It reports counts and flags the specific patterns it finds, so you can scan a snippet or a whole page and see where to look first. It does not execute scripts, request files or open your live page. It reads only the text you paste, and the checks are intentionally limited. Think of it as the first pass before you use a full validator or an accessibility audit, not as a replacement for either of them.
Why browser parsing matters
The tool relies on the same kind of parser that browsers use. Browsers are forgiving. When markup is broken, for example when a closing tag is missing or an element is placed where it is not allowed, the parser repairs it and builds a working page anyway. This is helpful for visitors, but it can hide problems from you.
Because the checker sees the repaired structure and not the raw text, some errors in your source may not be reported. A snippet that looks wrong can pass, and the reverse can also happen when the parser moves elements around. If you need strict conformance checking, use the W3C validator in addition. The two tools answer different questions: this one tells you what common issues exist in the parsed structure, and the validator tells you whether the source follows the specification.
Duplicate IDs
An id attribute is supposed to be unique within a page. When two elements share the same id, scripts and styles that rely on it may act on the wrong element, anchor links may jump to the wrong place, and form labels can attach to the wrong field. These problems often appear after copying a component several times, or when a template and a plugin both create the same id.
When the checker flags duplicates, search your source for the id and decide which element should keep it. Rename the others to something unique and update any CSS, JavaScript or links that referred to them. Fixing duplicates is simple, and it prevents confusing behavior that is difficult to track down later.
Images and links
Images should have alt attributes so that people who cannot see them still understand the page, and so that search engines have a text description. The checker flags images that lack them. For a deeper review of alt text, the Image Alt Text Checker on this site lists the missing and empty cases separately.
Links should have a destination and meaningful link text. Anchors with no href are not real links, and links with empty text give no information to screen readers. Review each flagged link to see whether it is a placeholder, a script-driven button that should be a button element, or a genuine link that needs text. Clear links help both usability and crawling.
Form labels
Every form field needs a label so that people know what to enter, and so assistive technology can announce the field correctly. A label can be attached by wrapping the input in a label element, or by using a for attribute that matches the field's id. A placeholder is not a replacement for a label, since it disappears when typing starts and is not reliably read by every tool.
If the checker flags fields without labels, add a visible label wherever possible. If the design truly requires hiding the label, use an accessible hidden-text technique, or an aria-label, and make sure the purpose is still clear. Because labels connect to ids, fix duplicate id problems first, since a shared id can break the link between a label and its field.
Accessibility needs human context
Automated checks can find missing attributes, but they cannot judge whether the content is understandable. They do not know whether the colors have enough contrast, whether the page can be used with a keyboard only, whether alt text is accurate, or whether headings and link text make sense in context.
Use this checker as a quick filter, then test the page the way people use it. Tab through it using only the keyboard, zoom the text, try a screen reader if you can, and check the page on a phone. For formal accessibility work, use a dedicated tool or review process based on the Web Content Accessibility Guidelines. A clean result here is a good start, not proof that the page is accessible.
Fix and verify
Work through the results in order of impact. Fix duplicate ids and missing labels first, since they can break behavior. Then address images without alt text and links without useful text. After each round of edits, paste the updated markup and run the checker again to confirm that the flags are gone.
Finally, validate the final rendered page with specialist tools, such as the W3C validator and an accessibility checker, and check it in several browsers. The tool cannot assess every rule of HTML, and its checks are not exhaustive. It is meant to save you time on common issues, and to give you a clear starting point for a careful review before you publish.
More HTML & Developer Tools · Browse the tools catalogue