HTTP content negotiation
Accept-Language Parser and Locale Matcher
Parse Accept-Language priorities and compare them with available locales. Inspect q-values and the lookup result before debugging server negotiation.
Input is processed locally in this browser
Accept-Language parser workspace
Parse priorities, validate q-values, and run RFC 4647 language lookup.
Separate tags with commas or new lines. The first equally suitable tag wins.
Parsed ranges
5
Available tags
5
Best lookup match
fr
| Priority | Language range | Quality | Meaning |
|---|---|---|---|
| 1 | fr-CA | 1.000 | Acceptable |
| 2 | fr | 0.900 | Acceptable |
| 3 | en-US | 0.800 | Acceptable |
| 4 | en | 0.700 | Acceptable |
| 5 | * | 0.100 | Acceptable |
Read language preferences without guessing
Parse Accept-Language priorities and compare them with available locales. Inspect q-values and the lookup result before debugging server negotiation. The header expresses language preferences rather than a binding server choice. Quality values rank preferences; q=0 marks a range as unacceptable. The lookup result depends on the available locale list, and an application may apply account settings or another negotiation policy.
How to use the Accept-Language parser
- Paste the field value from DevTools, a proxy log, or an API test. Including the
Accept-Language:name is optional. - Enter the language tags your application serves, separated by commas or new lines.
- Review the ranked table and correct any invalid range or quality value.
- Use the best lookup match as a debugging result, then verify your server's real selection and fallback policy.
Quality is preference, not a percentage
en;q=0.8 does not mean the user understands 80% English. It only ranks English below ranges with a larger q-value. Three decimal places are allowed; q=1.0000 and q=1.1 are invalid.
Lookup progressively truncates
When fr-CA is unavailable, lookup can fall back to fr. It does not automatically choose fr-FR as an exact regional substitute unless that tag matches a progressively truncated range in the offered list.
Standards and production limits
Syntax and quality semantics follow RFC 9110 §12.5.4. Matching follows the lookup scheme in RFC 4647 §3.4. The tool validates the field's practical grammar, but it does not download the current IANA Language Subtag Registry or prove that every well-formed subtag is registered.
If a response changes by language, evaluate whether the response needs Vary: Accept-Language; adding it blindly can fragment shared caches. Account settings, explicit URL locales, or a language selector are usually more stable than passive header detection.
Frequently asked questions
What does a missing q-value mean in Accept-Language?
A language range without q has the default quality value 1, the highest preference. The order still breaks ties between ranges with equal quality, so the parser preserves original position while sorting the report.
Why is q=0 shown as explicitly unacceptable?
RFC 9110 defines quality value zero as not acceptable. The matcher therefore excludes an available tag covered by a q=0 range instead of treating it as a low-priority fallback.
Does the best match guarantee which language a server returns?
No. The result applies RFC 4647 lookup to the preferences and available tags you enter. A real origin can ignore the header, use another matching scheme, apply account settings, or return a default representation.
Are pasted request headers sent to Toolk?
No. Header parsing and locale lookup run in the active browser tab. Toolk page analytics do not receive the header or the available language list entered into this tool.
Related tools
Last updated: September 15, 2026