Unicode & i18n

BCP 47 language tag parserCheck tags and header weights

Inspect one tag or switch to an Accept-Language header; the two inputs use different rules.

BCP 47 language tag parser

Input

Parsing stays in this browser; input is not sent or saved.

Parsed result

Parsing…

Options

Text direction
مرحبا 123 ABC

IANA registry snapshot: …

Parsing…

A localization bug often starts with a small tag such as zh-Hant-TW. This BCP 47 language tag parser keeps the original string beside its fields, so a script is not mistaken for a region.

A BCP 47 validator checks syntax and the dated registry here. The language subtag lookup and locale code normalizer are visible in the result, while Accept-Language parser mode has its own q rules.

Why use this BCP 47 language tag parser

Separate structure from registration

The BCP 47 language tag parser shows language, script, region, variants and extensions, then checks public subtags against the IANA snapshot. A browser may accept an unregistered region; the two verdicts remain distinct.

A segmented tag leads to language, script and region cards checked against a dated registry.

Read preferences without choosing a locale

Accept-Language weights are displayed from highest q to lowest, with equal weights preserving input order. A zero weight remains visible as excluded; this is analysis, not a promise about a server response.

Weighted language preference bars form a ranked list above a separate text direction preview.

Check the assumptions hidden in a locale string

01

Start with the right syntax

A lone tag goes in Language tag mode. For a copied HTTP value, switch to Accept-Language; it accepts an optional header name and keeps q parameters out of tag validation.

02

Compare two kinds of validity

The suggested form changes casing and known deprecated codes, but never edits the input. Read both the structural parse and the dated IANA verdict; a private-use tag has no public subtag meaning.

03

Control refresh and direction separately

Automatic parsing waits 350 ms after edits. Turn it off for Parse or Ctrl/Cmd+Enter. The RTL preview has its own auto, left-to-right and right-to-left choices because language alone cannot set base direction.

What the parser actually reports

Field-level subtag records

Language, extended language, script, region and variant each retain their code and registry description. Duplicate variants and extension singletons are flagged instead of disappearing during normalization.

A dated canonical suggestion

The IANA File-Date is shown beside the result. Deprecated values suggest their preferred form, while the browser canonical form is identified separately so CLDR or ICU differences stay visible.

Header weights and wildcard

The Accept-Language parser gives omitted q a value of 1, accepts at most three decimals and keeps the wildcard distinct from a tag. q=0 is shown as not acceptable, not silently removed.

Where a valid code stops being proof

Registration is not product support
The registry says whether public subtags exist in this snapshot. It cannot establish that a site, translation, font, operating system or API supports that language.
POSIX and ICU identifiers are separate
An underscore, encoding suffix or @modifier such as en_US.UTF-8 is not repaired into BCP 47. Convert that syntax elsewhere before using this tag parser.
No negotiation or direction inference
A weighted header does not identify the user’s actual locale or select a server representation. RTL preview direction is a separate text choice, not inferred from the tag.
Canonical form remains a suggestion
Casing and deprecated replacements appear beside the original. Parsing never rewrites input, builds a new header or generates application code.
Private use has no public meaning
An x-... tag can be syntactically valid, but IANA does not define its private tail. Registration checks use the displayed snapshot date and never fetch updates.
One header value, not an HTTP request
Header mode reads an Accept-Language value or that single header line. It does not inspect full requests, cookies or authentication headers.

BCP 47 language tag parser questions

Which language tag is right for me? How do I choose language and other subtags?

Use the shortest tag that identifies the content: language first, then script or region only when the distinction matters. This tool exposes the fields and registered subtags but cannot decide your product’s audience.

What is the expected format of HTTP Accept-Language locale string?

A header contains comma-separated language ranges such as en-GB and optional ;q=0.8 weights. Paste the value or the full Accept-Language line into Header mode; a single tag field does not accept q.

What is q=0.5 in Accept* HTTP headers?

It gives that range a preference weight of 0.5 relative to ranges with higher q. It is not a probability; q=0 means not acceptable. Equal weights remain in their input order here.

Can we derive base direction from language?

No. A tag identifies language attributes, not the base direction of arbitrary mixed text. Use the independent preview direction switch; auto follows the first strong character in the preview.

What is BCP 47 and when should I use it?

BCP 47 is the language-tag format used by web lang values and many localization APIs. Use this parser when inspecting a tag’s parts, registry status or canonical suggestion, not to test whether an app has translations.

Found a tag we misread?

Try the BCP 47 language tag parser on your next tag

Keep the original value visible, compare its suggested form and IANA status, then inspect header weights or a separate RTL text preview when needed.