Language Tag Validator: Check HTML Lang Values and Locale Identifiers

An html lang validator checks whether a page-language value follows recognized BCP 47 locale-tag syntax and shows a canonical spelling when the browser’s internationalization engine can normalize it. Enter one or several tags, such as en-US, fr-CA, or zh-Hant-TW, and inspect the reported language, script, region, validation status, and warnings. You can also paste HTML to check the opening html element for a missing or repeated lang attribute and to compare lang with xml:lang. The validator does not translate content or identify its actual language; it evaluates supplied declarations and draws attention to structural mistakes that need review.

HTML Lang Validator At a Glance

Why the Root Language Declaration Matters

Browsers and assistive technologies use declared language information to interpret text in appropriate ways, including pronunciation rules and language-specific processing. A document containing English prose but marked as French may be read with unsuitable speech rules, producing confusing results even when the visual display appears ordinary. Search engines also encounter language metadata, but a lang attribute is not a substitute for properly localized content, language-specific URLs, or other internationalization decisions. The root html attribute establishes the default document language; passages in another language can be marked separately on elements within the document. This tool concentrates on the declared values, rather than treating a valid string as evidence that the page’s language semantics are correct.

Recognize the Parts of a BCP 47 Tag

A familiar language tag begins with a language identifier and can include further subtags for script, region, variant, or extension details. English for the United States is commonly written en-US, while Simplified Chinese is often represented as zh-Hans and Traditional Chinese as zh-Hant. Script and region are not interchangeable: a script describes a writing system, while a region identifies a geographic locale convention. The validator displays language, script, and region fields when they can be derived from the parsed tag. That output helps distinguish a typo from an intentional locale choice, but it should not be interpreted as a complete registry record. Some language tags have historical forms, variants, or extensions that require additional editorial attention.

Use Hyphens Rather Than Programming-Locale Underscores

A common source of invalid HTML language metadata is copying a locale identifier from software configuration without adapting its syntax. Developers often see en_US or pt_BR in application APIs, database records, and operating-system settings. BCP 47 language tags generally use hyphen-separated subtags, so the equivalent HTML declarations are en-US and pt-BR. The validator flags underscore-separated input instead of silently rewriting it into a valid value. That distinction is useful for quality assurance: an invalid source value should be fixed in the actual markup or content management system, not concealed by an automatic correction in a report. If a tag is recognized but uses a noncanonical capitalization or alias, the report presents its canonical representation for review.

Understand Canonicalization Versus Validation

The browser’s Intl implementation may normalize a supported tag to conventional casing or update aliases according to its embedded locale data. That normalization is useful when an organization receives tags from several systems and wants to compare them consistently. It is not a guarantee that every historically registered or private-use form will be handled with the same breadth as a dedicated IANA Language Subtag Registry validator. Browser versions and their internationalization data can differ. This workspace reports what its environment recognizes and calls out private-use subtags when present. Where a publishing workflow depends on exact registry status or a specialized linguistic variant, consult the authoritative language-subtag data instead of relying only on a browser compatibility result.

Check the Opening HTML Element, Not Just a Text Field

A language tag that passes syntax validation can still be absent from the page where it is needed. Paste an HTML source sample and the tool searches for the opening html element, extracting lang and xml:lang values when present. It reports whether lang appears more than once and warns if a legacy xml:lang value differs. This is a source-level convenience check, not a browser HTML conformance parser or a live URL crawl. For complex templates, conditional rendering, or client-side language switching, inspect the delivered HTML and the final DOM separately. The existing HTML language attribute checker is useful when inspecting broader markup and nested language declarations, while this validator focuses on syntax and normalization of the tags themselves.

Worked Example: English, French, and Chinese Pages

Suppose a publishing site serves English, Canadian French, and Traditional Chinese versions of a support article. Paste en-US, fr-CA, and zh-Hant-TW on separate lines. The validator should identify each as a recognizable tag and expose the language, any script, and any region components. Now add pt_BR and observe that it is rejected because the separator uses an underscore. Correct that source declaration to pt-BR, then check the root HTML of each language version. A page translated into Canadian French should not be deployed with lang="en-US" simply because the base layout template was copied from the English version. Record any mismatches before updating the publishing templates.

Mark Embedded Language Changes Where Appropriate

An English-language page can contain an original French quotation, a Spanish product name, or a phrase in Arabic. A root lang="en" declaration describes the page’s primary language, but it does not automatically describe every embedded phrase correctly. Authors may need local lang attributes around passages with a different language so speech output can switch pronunciation rules. The value chosen for the embedded element still must be meaningful and syntactically appropriate. This tool can validate those individual values when they are pasted as tags, but it does not locate every foreign-language span or decide which fragments should receive an override. That judgment requires a content reviewer who understands the text and the intended audience.

Account for Directionality Separately

Language and text direction are related but different properties. A tag such as ar can identify Arabic language content, but developers also need to consider directionality, bidirectional runs, numerals, and the dir attribute where applicable. A language tag alone does not impose correct right-to-left layout, nor does right alignment substitute for correct direction semantics. When testing multilingual interfaces, inspect navigation, form labels, placeholders, error messages, and dynamically inserted content. Use realistic mixed-language strings containing numbers and punctuation rather than only short words. The validator deliberately does not offer a pass/fail verdict on bidirectional layout because it does not render the complete document or inspect computed text direction.

What Canonical Case Does and Does Not Mean

Canonical language tags often use lowercase primary language subtags, title-case script subtags, and uppercase region subtags. For example, zh-Hant-TW uses a visually distinct pattern that can make the parts easier to read. This is a conventional representation, not evidence that uppercase and lowercase values express different human languages. The validator can show an input and its canonical result so editors can standardize metadata across templates. Avoid confusing appearance with semantic accuracy: an impeccably capitalized tag can still describe the wrong language. Source metadata should come from the publication’s actual locale configuration or reviewed translation workflow, and should be checked again after migration or template changes.

Prevent Metadata Drift in a Multilingual Site

Language mistakes often emerge during ordinary maintenance. A new template may inherit the default site language even when it serves a translation; a cached fragment may retain an outdated locale; or a content export may convert hyphens to underscores. Include representative page samples in quality assurance whenever navigation templates, rendering routes, or localization libraries change. Test both static HTML and the DOM after client-side navigation if the application updates the document language dynamically. When reviewing a multilingual release, compare the declared lang value with visible headings, the page title, navigation text, and the primary body language. A syntactically valid tag is only one piece of that evidence, not a replacement for editorial review.

Export Results Without Converting Warnings into Facts

The report can be copied or downloaded as text, while JSON export preserves individual input values, normalized forms, and the root-HTML observation. Those outputs are useful for development tickets and controlled test records. A valid result means the browser accepted the supplied tag in this context; it does not prove that a translation exists or that a screen reader will pronounce every embedded phrase correctly. Invalid inputs should be corrected upstream, then rerun through the validator. If a tag uses a specialized private extension, annotate its purpose in the review rather than interpreting all warnings as definite errors. Keep the original input in audit records so the reason for a change remains visible.

Limitations and Manual Language Testing

The tool uses the environment’s internationalization parser and a bounded source scan. It does not query external registries, fetch a live page, read PDF language metadata, or evaluate the full accessibility tree. Detection of the opening html attribute is not equivalent to validating an entire HTML document. For production checks, examine the rendered DOM in developer tools, navigate translated interfaces with a keyboard, and listen with assistive technology configured for the relevant language. Check document titles, menus, form errors, and third-party embedded components, because one correct root attribute cannot fix content in another language or a widget that does not update its locale. Report specific mismatches instead of issuing a blanket multilingual accessibility verdict.

Frequently Asked Questions About HTML Language Tags