HTTP · i18n · locale negotiation

Accept-Language Header Builder & Tester

Build realistic browser or API locale headers, tune q-values, simulate server matching, and generate copy-ready snippets for Express, Nginx, and browser tests — all in one self-contained page.

Header builderCompose ordered locales with normalized q-values and wildcard support.

Negotiation previewTest exact match, primary-language fallback, and default locale selection.

Privacy awareSee when verbose headers leak more regional detail than you probably need.

Header builder

Use specific regions when they matter, keep q-values descending, and add a wildcard only if your backend really uses it.

Auto-distribute q-values from top to bottom Append *;q=0.5 wildcard fallback Add a space after commas for readability

Default server locale used when no match is found

Matching mode simulation behavior

Generated output

Everything updates live. Use the copy buttons to grab production-ready strings.

Accept-Language header

navigator.languages array

Quick advice

Locale negotiation tester

Paste the locales your app supports, then see which one wins and why.

Supported locales comma, space, or newline separated

Test a custom Accept-Language header leave empty to use the builder output

Server snippets

Copy a starter and wire in your real supported locales.

What to watch for

Very long locale lists can reveal more about a user than your app actually needs.
If your backend varies content by language, make sure caching layers also vary by Accept-Language.
Exact-only matching is simpler, but users often expect en-GB to fall back to en.
For APIs, sending one or two explicit locales is usually cleaner than copying a full browser header.