HTML Language Attribute Checker
Preparing workspace…
An HTML lang checker examines the language declared on the document’s html element, reviews nested lang and xml:lang attributes, and checks hreflang tag syntax where present. Enter a public HTML URL that the restricted inspection endpoint can retrieve or paste an HTML sample for offline review. The checker applies BCP 47 tag canonicalization through the browser’s internationalization APIs, identifies missing or malformed declarations, and reports differences between root language attributes. It cannot determine the true language of a paragraph from its words or confirm how a particular screen reader pronounces content. Its findings describe language-tag markup, not a translation-quality assessment or full accessibility certification.
HTML Lang Checker At a Glance
| Factor | Details |
|---|---|
| Primary check | Presence and syntax of html lang |
| Related attributes | Root xml:lang and nested element lang |
| Alternate links | hreflang values including x-default |
| Validation | Intl canonical language-tag parsing |
| Reporting limits | Up to 250 nested and 250 hreflang elements |
| Exports | JSON findings and nested-language CSV |
Why the Root HTML Language Matters
The language declared on the html element supplies a machine-readable default for the document. Assistive technology can use this information to choose appropriate pronunciation rules, while other software may rely on it for language-sensitive processing. For example, a predominantly English page might begin with <html lang="en">, while a page written for French readers might use fr. A missing root declaration can make language handling less predictable, especially when the operating system’s preferred language differs from the page content. The attribute does not translate the text and does not force search engines to classify the document in a particular language. It simply declares what the author intends the document language to be.
BCP 47 Language Tags and Canonical Forms
BCP 47 language tags may contain a primary language subtag and additional subtags for region, script, variants, or other registered information. Examples include en-US, pt-BR, and zh-Hant. The checker asks the browser’s Intl.getCanonicalLocales implementation to validate and canonicalize a supplied tag. The resulting spelling or capitalization may differ from the source, which is reported as a note rather than automatically treated as a fatal error. Canonicalization is a syntax and registry-based operation; it cannot prove that the author selected the correct language for the actual words on the page. Nor does every possible locale behavior map perfectly to the language needs of all assistive technologies.
Root lang and xml:lang Differences
HTML documents commonly use lang, while xml:lang also appears in XHTML and other XML-based contexts. If both are present on the root element, mismatched declarations can create uncertainty about which language metadata an application should use. The checker presents both values and flags when their canonicalized forms differ. An intentionally multilingual page may still have one default root language, with local overrides on specific spans or paragraphs. Those overrides are not substitutes for setting a root default. Before changing attributes on an XHTML document, inspect the actual document format and the way it is served; HTML parsing rules and XML parsing rules are not always interchangeable.
How Nested Language Overrides Work
A page can be mainly English and include a short phrase in another language. Marking that specific phrase with a nested lang attribute allows compatible software to switch language handling for the relevant content. The checker scans up to 250 elements carrying a lang attribute and reports the declared value and its canonical interpretation. It does not automatically judge whether an individual phrase needs a language switch or whether the text genuinely matches the declaration. That editorial decision depends on context, pronunciation, and the structure of the page. A foreign-language product name, for example, may require different treatment from a complete sentence embedded in a translation.
Worked Example: English Page with a Spanish Quotation
Consider a page whose main language is en, with a Spanish quotation placed inside a blockquote element. A correctly scoped nested declaration might use lang="es" on the quotation container while preserving the English root setting. The report should show a valid English root and a nested Spanish declaration without treating the difference as an error. If the nested attribute were misspelled as a nonstandard string, the checker could report a malformed tag. It could not identify the quotation’s language from the words themselves, however. A human reviewer must verify that the quotation, translation, punctuation, and declared language all align with the published content.
Reviewing Hreflang Separately from Lang
The hreflang attribute on alternate page links describes the language or language-region relationship of an alternate URL; it is not the same as the lang attribute used on an element’s content. For example, a link may declare hreflang="de-DE" to describe a German-language alternate. The special x-default value can appear in hreflang annotations and is treated as a distinct supported token rather than as a BCP 47 locale. The checker validates the syntax of declared values and lists them, but it does not request every alternate URL, verify reciprocal annotations, evaluate canonical clusters, or establish that the translation exists. Those checks require broader multi-page inspection.
How to Run an HTML Language Check
Begin with a complete HTTP or HTTPS URL or choose offline mode and paste the source markup. When the live endpoint successfully retrieves a permitted HTML page, the checker parses its document element and collects language-related attributes. The summary reports the root declaration, inspected nested tags, alternate-tag count, and syntax errors. Review error messages before considering optional canonical-spelling notes. If you are working offline, remember that the markup may not match the deployed response. A templating system might insert a default lang value at runtime or serve localized HTML on another route, so an offline result should not be presented as a production verification.
Interpretation of Missing and Empty Values
Missing and empty attributes have different technical shapes, even though neither supplies a useful language declaration. The checker reports a missing html lang as an error and an explicitly empty value as a distinct invalid declaration. Nested empty lang values should also be reviewed because HTML language inheritance has subtleties when a language is intentionally unspecified. If a localization framework changes attributes during client-side hydration, the server-returned markup may disagree with the rendered DOM. Test both the initial document and the final accessible experience where that distinction matters. A static markup finding is a starting point for diagnosis, not a substitute for assistive-technology testing.
Limits of Programmatic Language Inspection
The tool uses structural HTML parsing and language-tag canonicalization. It does not run language detection on page text, compute translation similarity, identify dialect-specific phrasing errors, or simulate pronunciation in a screen reader. Even a valid lang value can be inappropriate if the content is written in a different language. Conversely, a document might contain proper localized text but omit a useful markup declaration. The inspector’s findings should be combined with multilingual editorial review, keyboard navigation, and assistive-technology testing. An ARIA attribute validator can identify some adjacent markup problems, but ARIA checks cannot replace a correct language declaration or native semantic HTML.
Maintaining Language Attributes Across Templates
A localized website may generate many pages from the same layout. When the locale changes by route or content record, the default language should change consistently with it rather than being hardcoded to one value across the entire site. Nested quotations, UI strings, user comments, and alternate-language references deserve deliberate handling. Export the report and compare representative pages after a template change, especially in environments using server rendering followed by client hydration. Keep the specific URL and inspection mode alongside the results, because language metadata can differ between locale routes or environments. A reliable workflow verifies the rendered content and the attributes together rather than optimizing only for a syntactically clean report.
Frequently Asked Questions
Can the checker detect the language of my written content?
No. It validates declared language tags. It does not read prose and decide whether the declaration matches the author’s actual language.
Is en-us invalid compared with en-US?
A browser may canonicalize casing to en-US. Canonical-spelling notes are not necessarily syntax errors; the tag should still be reviewed in context.
Should every foreign product name have a nested lang?
Not automatically. The need for a language switch depends on context, pronunciation, and how the phrase is used in the surrounding text.
Does hreflang replace the root lang attribute?
No. Hreflang describes an alternate URL relationship; the root lang describes the language of the current document.
What does x-default mean?
It is a special hreflang marker used for a default or language-selection URL, not an ordinary language identifier passed to Intl locale canonicalization.
Will a correct lang attribute guarantee accessibility?
No. It addresses one aspect of language metadata. Semantic markup, focus behavior, readable content, and screen-reader checks remain important.
When a root language tag differs between the server response and a browser-rendered page, document which layer introduced the change before correcting it. A build pipeline may set the attribute from a locale variable while client code later replaces it, creating inconsistent behavior for technologies that read the document at different times. Verifying the original HTML and the final rendered DOM makes the reported evidence much easier to interpret.
Conclusion
Language metadata is most useful when it accurately describes the content and works with the page’s structure. Combine valid tags with editorial review and real assistive-technology testing rather than treating syntax alone as accessibility proof.