ISO 639-1 Language Codes

No Comments
Iso 639-1 language codes

ISO 639-1 is the standard of two-letter language codes (en, fr, de) that hreflang and HTML lang attributes are built on; region targeting adds a two-letter country code from a different standard, ISO 3166-1 alpha-2 (US, GB, FR). Get a code wrong and the annotation isn't "slightly off" — it's invalid and ignored, silently.

Two standards, one format

An hreflang value is either a language alone or a language-region pair:

hreflang="fr"        language only: French, anywhere
hreflang="fr-CA"     language-region: French, for Canada
hreflang="en-GB"     English, for the United Kingdom

The part before the hyphen must be an ISO 639-1 language code. The part after must be an ISO 3166-1 alpha-2 region code. Two consequences trip people constantly:

  • You can never target a region alone. hreflang="GB" is invalid — there's no such thing as "for the UK, any language" in hreflang. Language is mandatory, region is optional.
  • The two standards don't always agree with your intuition. Language codes come from the language's own name (Japanese is ja from nihongo's ISO assignment, German is de from Deutsch), while region codes follow country names — and they collide. se is the region Sweden but NOT the Swedish language (that's sv).

The classic: en-GB vs en-UK

The single most famous ISO code error in international SEO: writing hreflang="en-uk" for British English. UK is not a valid ISO 3166-1 region code. The United Kingdom's code is GB. Google has confirmed it special-cases this one because the mistake is so widespread — but building on an exception is how you learn that other systems (browsers, CDNs, other search engines, your own validation tooling) don't share Google's mercy. Write en-GB.

Common codes and the mistakes that come with them

What you meanCorrect codeFrequent mistakeWhy it happens
English for the UKen-GBen-UKUK is the everyday abbreviation; ISO says GB
SwedishsvseSE is Sweden the country, not Swedish the language
JapanesejajpJP is Japan the region; the language is ja
CzechcsczCZ is Czechia the region; the language is cs
GreekelgrGR is Greece; the language code comes from ellinika
DanishdadkDK is Denmark the region; the language is da
Simplified Chinesezh-Hans (or zh-CN)cnScript variants use ISO 15924 script codes; cn alone is a region
Any language, UK visitors— (impossible)gb aloneRegion-only targeting doesn't exist in hreflang

The pattern behind most rows: someone reached for the country code when they meant the language. If the code you typed matches the ccTLD (.se, .jp, .cz, .gr, .dk), be suspicious — you may be holding a region code.

Why invalid codes are worse than missing ones

Hreflang is a clustering signal, and an annotation with an invalid code simply drops out of the cluster — no error page, no warning in the HTML, nothing. Your sv pages and your se-annotated pages just quietly fail to connect, and Sweden gets whatever version Google guesses. Because failure is silent, code validation belongs in tooling, not eyeballs: the hreflang tag generator only emits valid codes, and the invalid hreflang annotations check covers how malformed codes surface in an audit. Remember also that codes are one layer of a correct setup — reciprocity, one single implementation method, and a fallback via x-default are the others, all covered in the hreflang implementation guide.

How to check it

  1. Crawl the site in Screaming Frog and open the Hreflang tab — filter for "Contains Invalid Language & Region Codes" (also check "Not Using Canonical"). This catches en-UK, se-for-Swedish, and friends in one pass.
  2. Extract every distinct hreflang value in use: curl -s https://example.com/ | grep -o 'hreflang="[^"]*"' | sort -u — run it against one URL per template. A site usually has fewer than a dozen distinct values; eyeball the short list against the table above.
  3. Check case and separator conventions: values are case-insensitive and Google tolerates underscores, but en-GB (lowercase language, hyphen, uppercase region) is the convention every other system expects — normalize to it.
  4. Confirm the same codes appear in your HTML lang attributes and your hreflang annotations. A page declaring lang="en" while hreflang calls it fr is sending contradictory signals.

Common mistakes

  • en-UK for British English. The region is GB. Fix: sitewide search-and-replace, then add a validation rule so it never ships again.
  • Country code where the language code belongs. se, jp, cz, dk, gr used as languages. Fix: validate the pre-hyphen part against the ISO 639-1 list mechanically — never from memory.
  • Region-only values. hreflang="us" hoping to target America in any language. Invalid — language first, always. Fix: en-US, or plain en if you don't need the region.
  • Inventing regional language variants. hreflang="eu" for "European English" — EU isn't a targetable region and there's no continental targeting in hreflang. Fix: list the country variants you actually serve, plus a bare en for the rest.
  • Codes drifting between systems. The CMS says fr-FR, the sitemap generator emits fr_fr, a plugin adds fr. Fix: one canonical code list in one config, consumed by every system that emits language codes.

FAQ

Are hreflang codes case-sensitive?

No — en-gb, EN-GB, and en-GB all work. The en-GB convention exists for humans and for stricter systems (like the HTML lang attribute ecosystem), so use it anyway.

What about languages with no two-letter code?

Hreflang accepts ISO 639-2/639-3 three-letter codes when no 639-1 code exists (Filipino fil is the common real-world case). If a two-letter code exists, you must use it.

Can I target a language variant like Brazilian vs European Portuguese?

Yes, via regions: pt-BR and pt-PT. Add a bare pt (or x-default) so Portuguese speakers outside both countries still match something.

Is en-US redundant if my site is just in English?

If you have one English version, plain en says exactly what you mean and can't go stale. Reach for en-US only when a second English market exists to distinguish from.

Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.

About SEO ProCheck

Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.

Work With Me

Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.

Subscribe to our newsletter!

More from our blog