Hreflang Language Codes: The Complete List and Rules

Summarize this post with: 22 min read

ChatGPT Perplexity Grok Google AI

An hreflang value is a two-letter ISO 639-1 language code (for example fr), optionally followed by a hyphen and a two-letter ISO 3166-1 alpha-2 region code (for example fr-CA for French speakers in Canada). The language always comes first, a region can never be used on its own, and the reserved value x-default marks the fallback page. Google does not support other code systems, so UN M.49 area codes such as es-419 for Latin American Spanish are ignored.

Key takeaways

• Format: language or language-REGION, e.g. de, de-AT, pt-BR. Case does not matter to Google, but lowercase language and uppercase region is the convention.
• Use ISO 639-1 for the language and ISO 3166-1 alpha-2 for the region. Nothing else is supported, including es-419, en-UK and en-EU.
• A script subtag from ISO 15924 is allowed when you need it: zh-Hans, zh-Hant, sr-Latn.
• Every page in a set must list itself and all its alternates, and each alternate must link back.
• Add x-default for the page you want people to see when no listed language or region matches.

The full lists of valid language codes and region codes are further down this page. The rules come from Google’s own documentation, Tell Google about localized versions of your page, which Google last updated on 21 September 2026.

How an hreflang code is built

An hreflang value has up to three parts, separated by hyphens:

So all of these are valid: en, en-GB, zh-Hant, zh-Hant-TW, sr-Latn. The first part must be a language. As Google’s documentation puts it, you can’t specify the country code by itself. Its example is Belgium: nl-BE (Dutch for users in Belgium) and de-BE (German for users in Belgium) are correct, while be on its own means Belarusian, not Belgium.

Google also says the value is case-insensitive. en-gb, EN-GB and en-GB all work. Most teams write the language in lowercase and the region in uppercase because that is how the ISO lists print them, and it makes mistakes easier to spot in code review.

Language-only or language plus region?

Use a language-only code (es) when one page serves every speaker of that language, wherever they live. Most sites translated with a website translation tool fall into this group: one Spanish version, one German version, and so on.

Add a region (es-MX, es-ES) only when you really have different pages for different countries. Good reasons are different prices or currencies, different shipping and legal text, or deliberately different wording (for example pt-BR and pt-PT, or en-US and en-GB with local spelling and prices).

You can mix both. A common pattern is a generic page plus regional exceptions:

<link rel="alternate" hreflang="es" href="https://example.com/es/" />
<link rel="alternate" hreflang="es-MX" href="https://example.com/es-mx/" />
<link rel="alternate" hreflang="en" href="https://example.com/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

A searcher in Mexico gets the es-MX page; a Spanish speaker in Chile, Spain or the US gets the generic es page.

What about Latin American Spanish (es-419)?

This is the most common question about hreflang codes, and the answer is short: Google does not support es-419. Its documentation names it as the example of an unsupported code, because 419 is a UN M.49 area code (“Latin America and the Caribbean”), not an ISO 3166-1 country code. The same applies to other M.49 numbers such as 150 (Europe).

If you have one Latin American Spanish page, you have two workable options:

1. Mark it as plain es. If you have no separate Spain version, this is the simplest choice and covers every Spanish speaker.
2. List the countries individually. If you also have a Spain page (es-ES), point several country codes at the same Latin American URL: es-MX, es-AR, es-CO, es-CL, es-PE and so on. One URL can carry several hreflang values.

The same thinking applies to French for Africa, Arabic for the Gulf, or “English for Europe”: there are no supported region groups, so use the language alone or list the countries.

x-default: the fallback value

x-default is not a language. It is a reserved value that Google uses “when no other language/region matches the user’s browser setting”. Point it at a language selector page or at your main version:

<link rel="alternate" hreflang="x-default" href="https://example.com/" />

It is optional, but it is worth adding. Without it, a visitor whose language you don’t cover gets whichever version Google picks.

Where the code goes: three ways to implement hreflang

Google accepts hreflang in three places. Pick one method per page; you don’t need all three.

1. HTML <link> tags in the <head>

<link rel="alternate" hreflang="en" href="https://example.com/pricing" />
<link rel="alternate" hreflang="de" href="https://example.com/de/pricing" />
<link rel="alternate" hreflang="fr-CA" href="https://example.com/fr-ca/pricing" />
<link rel="alternate" hreflang="x-default" href="https://example.com/pricing" />

2. HTTP Link headers (useful for PDFs and other non-HTML files)

Link: <https://example.com/guide.pdf>; rel="alternate"; hreflang="en",
      <https://example.com/de/guide.pdf>; rel="alternate"; hreflang="de"

3. XML sitemap entries

<url>
  <loc>https://example.com/pricing</loc>
  <xhtml:link rel="alternate" hreflang="en" href="https://example.com/pricing" />
  <xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/pricing" />
</url>

Whichever you choose, three rules from Google’s documentation apply:

• Each version lists itself and every other version. The set on the German page is the same as the set on the English page.
• Links must be reciprocal. If page X points to page Y, page Y must point back to X, or the annotation can be ignored.
• URLs must be fully qualified, including https://. /de/pricing or //example.com/de/pricing are not accepted.

For a full walk-through of the implementation itself, including canonicals and testing, see our complete hreflang guide and the explainer on self-referencing hreflang tags.

The most common hreflang code mistakes

Most broken hreflang sets we see come down to a handful of wrong codes. Several of them are valid codes that simply mean something else, so validators don’t always flag them.

The pattern behind most of these: people type the country code where the language code belongs. Japan is JP but Japanese is ja; Sweden is SE but Swedish is sv; Denmark is DK but Danish is da.

Other frequent problems are not about the codes at all: missing return links, relative URLs, hreflang pointing to a URL that redirects or is blocked, and a canonical tag that points every language version to the English page. Our article on the no-return-tags error covers how to fix those.

Chinese, Serbian and other languages with more than one script

Some languages are written in more than one script, and the script matters more than the country.

• Chinese. Use zh-Hans for Simplified and zh-Hant for Traditional if your pages differ by script rather than by country. If they are country-specific, zh-CN, zh-TW and zh-HK work too; Google notes that with zh-TW the script (Traditional) is derived from the region. You can be explicit with zh-Hant-TW.
• Serbian. sr-Latn and sr-Cyrl separate the Latin and Cyrillic versions.
• Norwegian. ISO 639-1 has no (Norwegian), nb (Bokmål) and nn (Nynorsk). Most Norwegian websites are in Bokmål; use whichever code matches the text and stay consistent.

Common language and region combinations

These are the combinations most multilingual sites need. All are valid under Google’s rules.

How ConveyThis sets hreflang codes for you

If you translate your site with ConveyThis, you don’t write these tags by hand. When you use a subdomain or subfolder URL structure, ConveyThis adds hreflang tags for every language you publish, using the correct language codes, together with translated page titles and meta descriptions. That removes the two errors behind most broken sets: wrong codes and missing return links. You can read what else it handles on the multilingual SEO page, and the URL structure guide explains which structure to pick and which plans include it. Subdomains and subfolders are available from the Business plan; see pricing for the details.

If you build hreflang yourself, the reference lists below are the only codes you need.

Complete list of hreflang language codes (ISO 639-1)

All 183 two-letter codes in ISO 639-1, as published by the Library of Congress, the ISO 639-2 registration authority. Any of them can be the first part of an hreflang value. Where a code has several names, they are separated by a slash.

Complete list of hreflang region codes (ISO 3166-1 alpha-2)

All 249 officially assigned ISO 3166-1 alpha-2 codes. Any of them can follow the language code, e.g. en-IE or ar-EG. Codes that are not on this list, such as UK, EU or XK, or numeric UN M.49 codes such as 419, are not supported by Google.

Frequently asked questions

Is hreflang case-sensitive? No. Google accepts en-gb, EN-GB and en-GB. Lowercase language plus uppercase region is the usual convention.

Should I use an underscore, as in en_US? No. hreflang values use a hyphen: en-US. The underscore form comes from software locale settings, not from hreflang.

Can I use three-letter language codes? Google’s documentation only supports ISO 639-1 language codes, which are all two letters. A language that only has a three-letter code (ISO 639-2 or 639-3) isn’t in the supported list.

Does Google use the HTML lang attribute instead? No. Google determines a page’s language from its visible content and doesn’t use code-level signals such as lang attributes, according to its guide to multi-regional and multilingual sites. Keep lang for accessibility and browsers, and use hreflang to connect the versions.

Do I need a region code for every page? No. Most translated sites only need language codes. Add regions when the pages really differ by country.

Want every page connected with correct hreflang codes automatically? Create a ConveyThis account and add your first language.