How to fix a missing html lang attribute

Set a valid language code on the root element: <html lang="en">. Screen readers use it to choose the correct pronunciation rules, and without it a French page may be read aloud with English phonetics. It is a WCAG Level A requirement and a two-second fix.

Last updated 2026-07-28

What does the lang attribute actually do?

It tells software what language the page is written in, and the software that cares most is the screen reader. Voice synthesisers load a different pronunciation model per language, so the declared value decides whether French text is spoken with French phonetics or read letter-by-letter through an English voice.

On a page with no lang attribute, a screen reader falls back to the user's system language. For an English user on a French page that produces something close to noise — recognisable words rendered unrecognisable, at speaking speed, with no way to correct it.

Several other things depend on it too: browsers use it to choose language-appropriate fonts, quotation marks and hyphenation rules, to decide whether to offer a translation prompt, and to apply the correct :lang() CSS selectors. Search engines read it as a supporting signal when classifying the content language.

What language code should I use?

Use the two-letter ISO 639-1 code for your language on its own — lang="en", lang="fr", lang="de" — and add a region subtag only when the regional variant genuinely changes something. The format is defined by BCP 47: language first, optional region second, separated by a hyphen.

lang="en" is the right answer for the large majority of English sites. Reach for lang="en-GB" or lang="en-US" when spelling conventions matter to you, or when you want a screen reader to use a specific accent for a regional audience. Do not invent codes: "en-UK" is not valid (the country code for the United Kingdom is GB), and a region code alone is never a language.

An empty lang="" is worse than no attribute at all — it explicitly declares "no language" and some assistive technology treats that as a hard instruction rather than falling back gracefully.

Where does it go, and how do I mark other languages inline?

It goes on the <html> root element, once per page, and any passage in a different language gets its own lang attribute on a wrapping element. The root value declares the page default; inline values override it for as long as that element lasts.

Mark inline passages when the language genuinely changes — a quotation, a foreign phrase, a product name in another language. Do not mark loanwords that have entered normal usage in the page language, such as "café" or "genre" in English, because a screen reader switching voice mid-sentence for a single naturalised word is more disruptive than helpful.

Root element and inline exceptions
<!doctype html>
<html lang="en">

<!-- Regional variant when spelling or pronunciation differs -->
<html lang="en-GB">

<!-- Mark passages in another language inline -->
<p>The French call it <span lang="fr">référencement</span>.</p>

<!-- A whole quoted block in another language -->
<blockquote lang="de">Ordnung muss sein.</blockquote>

Is the lang attribute an accessibility requirement?

Yes. WCAG 2.1 success criterion 3.1.1 Language of Page requires the default human language of every page to be programmatically determinable, and it sits at Level A — the minimum conformance tier, not an aspirational extra. Criterion 3.1.2 Language of Parts covers the inline case at Level AA.

Automated testing catches it reliably, which is why it shows up in nearly every audit. axe-core implements three separate rules here: html-has-lang checks the attribute exists, html-lang-valid checks the code is well-formed, and valid-lang checks inline lang values on other elements. All three run in the accessibility pass of a standard Lighthouse audit as well.

Despite being a one-attribute fix, it remains one of the most frequently reported failures in large-scale scans of the top million home pages — a reminder that the barrier here is awareness rather than difficulty.

How is lang different from hreflang?

lang describes this page; hreflang points at other pages. The lang attribute tells a browser or screen reader how to render the content in front of it, while hreflang tells a search engine which of your translated URLs to show which searcher.

They are independent mechanisms and a multilingual site needs both. Getting hreflang right while leaving every page declaring lang="en" means Google serves the French page correctly and the screen reader then reads it in English — a fully correct international setup that is unusable for part of its audience. The reverse is just as common: correct lang attributes with no hreflang, so the right rendering reaches the wrong users.

How do I check it across a whole site?

Crawl the site and read the lang attribute on the root element of every URL, looking for missing values, empty values and invalid codes as three separate lists. In most cases the attribute comes from one shared layout, so the result is close to all-or-nothing — and the interesting rows are the handful of pages built outside that layout.

Audra checks the lang attribute on the root element of every crawled page and reports missing or empty values, while its axe-core pass raises the same issue as a WCAG violation with the specific rule named. Since the attribute usually lives in a single template, one edit typically clears the finding across the entire site and lifts the accessibility component of the Audra Score, which carries 25% of the total weighting.

The fix, step by step

  1. 1Find the base template that renders the <html> element.
  2. 2Add a valid BCP 47 code, such as lang="en" or lang="en-GB", and check it is not left empty.
  3. 3Mark inline foreign-language passages with their own lang attribute on a wrapping element.
  4. 4On a multilingual site, confirm each translated template declares its own language rather than inheriting the default.
  5. 5Re-crawl to confirm every page declares a valid language.

Frequently asked questions

Should I use lang="en" or lang="en-US"?

Plain "en" is right for most sites. Add a region subtag only when the regional variant genuinely matters for spelling or for the accent a screen reader should use.

Is the lang attribute an accessibility requirement?

Yes. WCAG 2.1 success criterion 3.1.1 (Level A) requires the default human language of each page to be programmatically determinable, and 3.1.2 (Level AA) extends that to passages in other languages.

Does it affect SEO?

It is a supporting signal for language classification rather than a ranking factor. Its main impact is accessibility, and on multilingual sites it works alongside hreflang rather than replacing it.

Is lang="" the same as leaving the attribute off?

No, it is worse. An empty value explicitly declares that the page has no language, which some assistive technology honours literally instead of falling back to the user's system language.

Related guides