skip to content

What does the lang attribute on the <html> element actually change in a browser, and when should you set lang on an element deeper in the page?

level: middleimportance: must knowfreq 54%

answer

  1. one line, large accessibility payoff
  2. BCP 47 tag, not a language name
  3. voice, hyphenation, glyphs, dictionary
  4. inherited down the subtree
  5. re-declare for a foreign phrase

basics

~20 s

lang declares the document's natural language with a BCP 47 tag, and it drives screen-reader pronunciation and voice choice, hyphenation and line breaking, font and glyph selection, the spellcheck dictionary, and translation offers. Set it again on any element whose content is in a different language.

solid answer

~50 s

`lang` tells every consumer of the page what human language the text is in, using a BCP 47 tag such as `en`, `en-GB` or `fr`. On `<html>` it is the single most impactful accessibility attribute you can add in one line: a screen reader picks its voice and pronunciation rules from it, and without it English pronunciation rules get applied to French text or the reader falls back to the user's OS language. It also selects the hyphenation and line-breaking rules, influences font and glyph selection for languages that share code points, chooses the spellcheck dictionary for editable fields, tells browsers and translation tools what to offer to translate, and is what the `:lang()` selector matches. Because `lang` is a global attribute it applies to a subtree and is inherited, so you re-declare it on any span, quote or block written in another language.

go deeper

for a junior

Know that <html lang="…"> declares the page language with a code like en or fr, that it is required on every page, and that it is what a screen reader reads the page with.

for a middle

List the concrete effects — voice and pronunciation, hyphenation and line breaking, glyph selection, spellcheck dictionary, translation, :lang() — and explain that the attribute is inherited so a foreign phrase needs its own lang.

for a senior

Argue why a wrong lang is worse than a missing one, handle user-generated content with dir="auto" and lang="", and know that language and direction are independent declarations.

for a principal

Own internationalisation as a system decision: how the language tag is derived per route, where translate="no" protects brand and code strings, and how a wrong tag is caught before it ships.

## What lang declares `lang` is a global attribute whose value is a **BCP 47 language tag** — `en`, `fr`, `de`, `ja`, or a more specific form like `en-GB`, `pt-BR`, `zh-Hans`. It states the natural language of the element's content and, because it applies to the whole subtree, everything inside inherits it until another `lang` overrides it. Declaring it once on `<html>` therefore covers the document: ```html <html lang="en-GB"> ``` The special value `lang=""` means "the language is unknown", which is different from omitting the attribute and is occasionally right for user-generated content of unknown origin. ## What it actually changes **Speech.** A screen reader uses `lang` to choose its voice and its pronunciation rules. With no declaration it falls back to the user's system language, so a French page read by an English voice becomes near-unintelligible. This is the reason `lang` on `<html>` appears in every accessibility audit checklist. **Line breaking and hyphenation.** Hyphenation dictionaries are per-language, and text engines will not hyphenate without knowing the language. Word-breaking rules differ dramatically too — languages that do not use spaces need language-aware segmentation. **Fonts and glyphs.** Chinese, Japanese and Korean share Unicode code points whose correct glyph shapes differ by language. Without `lang` the browser guesses, and the wrong regional glyph shape is immediately visible to native readers. **Spellchecking.** For editable content, the dictionary comes from the declared language, so an unlabelled or wrongly labelled document underlines every correctly spelled word. **Translation.** Browser translation features and translation services use it to decide the source language and whether to offer translation at all. **Selectors and quotes.** The `:lang()` pseudo-class matches on the declared language, and language-specific typographic conventions such as the quotation marks rendered by `<q>` follow it. **Case mapping.** Uppercasing is language-sensitive: Turkish distinguishes dotted and dotless i, so the same text uppercases differently under `lang="tr"`. ## Deeper in the page Because the declaration is inherited, you only re-declare it where the language genuinely changes: ```html <p>She called it a <span lang="fr">fait accompli</span> and moved on.</p> ``` Now the screen reader switches voice for those two words and switches back. Do this for foreign phrases and quotations, for a language switcher whose links name their target language (`<a href="/fr" lang="fr" hreflang="fr">Français</a>`), and for any user-supplied block in a known other language. Do **not** do it for loanwords that have been fully absorbed into the surrounding language — announcing every borrowed word in another voice is worse than leaving it alone. ## The related attributes `dir` is the companion global attribute and is a separate declaration: `dir="ltr"`, `dir="rtl"`, or `dir="auto"`, which asks the browser to infer direction from the first strong directional character in the content — the right choice for user-generated strings whose language you cannot know at render time. Language does not imply direction, so an Arabic or Hebrew page needs both `lang` and `dir="rtl"`. `translate="no"` is a third global attribute, and it asks translation tools to leave that element's text alone — appropriate for product names, code samples and identifiers that must not be translated. ## The common mistakes Omitting `lang` entirely is the big one. Close behind: copying a boilerplate `lang="en"` onto a page that is not in English, which is worse than nothing because it actively misdirects the screen reader; using a non-BCP-47 value such as a full language name; and putting a country code where a language code belongs — `en-GB` is valid because `GB` is a region subtag after the language, but `GB` alone is not a language.

  • How is dir different from lang, and when is dir="auto" the right choice?
    They are independent declarations: `lang` states the language, `dir` states the writing direction, and one does not imply the other. Set `dir="rtl"` explicitly for right-to-left content. `dir="auto"` tells the browser to infer direction from the first strong directional character in the content, which is the right tool for user-generated text whose language you cannot know when you render the page.
  • Is it worse to omit lang or to declare the wrong language?
    Declaring the wrong one is worse. With no declaration a screen reader falls back to the user's system language, which is at least sometimes right. A wrong declaration actively overrides that with a voice and pronunciation ruleset guaranteed not to fit, and it also misdirects hyphenation, spellchecking and translation. Boilerplate `lang="en"` on a non-English page is a real defect.
  • Should every foreign loanword in a sentence get its own lang attribute?
    No. Mark up genuine passages and quotations in another language, but leave words that have been absorbed into the surrounding language alone. Switching voice mid-sentence for a naturalised loanword is more disruptive to a screen-reader user than the slightly-off pronunciation you were trying to fix.

saying these in an interview costs you the question

  • Thinks lang changes text direction
  • Says lang only matters for search engines
  • Copies lang="en" onto a non-English page
  • Writes lang="English" or a country code alone
  • Believes lang must be repeated on every element

context

resolving links…