HTTP content negotiation
Accept-Language Parser & Matcher
Turn a raw Accept-Language header into an ordered preference table, catch invalid q-values, and test the best available locale with deterministic RFC 4647 lookup.
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
Accept-Language is a request field that lists language ranges in preference order. A missing quality value means q=1; smaller values are weaker preferences, and q=0 means the range is unacceptable. This parser makes those rules visible and then compares them with the locales your application can actually serve.
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 developer tools
Last updated: August 29, 2026
Need a different tool?
Browse all 99 browser-based tools (99 currently marked free), or tell us what useful utility we should build next.