🌐Dev

Accept-Language Header Parser and q Sorter

Sorts the browser language tags by their q factor, keeps ties in the order sent, and flags q=0 refusals, invalid q values and the * wildcard range.

Header

Sorted

—

Reading Accept-Language in the right order

The Accept-Language header arrives from the browser looking like a tidy list, but the order the languages appear in the text is not the order of preference. What rules is the q parameter, the quality factor, running from 0 to 1. An entry without q counts as 1 by default. So "en;q=0.5,pt-BR" puts Portuguese first, even though it is written last.

Paste the header as it arrives on the request and the page splits each entry, reads its q and reorders from highest preference to lowest, showing the effective value beside each one. It works both for checking what a real browser is sending and for understanding why language negotiation on the server picked the language it did.

One detail that trips people up: pt-BR and pt are different values, and a server that only compares exact strings will not find "pt" when the client asks for "pt-BR". The matching rule in RFC 4647 says to truncate the tag at hyphens until something matches — this page sorts, but your application decides the match. A q=0 carries its own meaning: it says "do not send me this", not "either is fine".

Frequently asked questions

What happens when two languages share the same q?

The specification defines no tie-break, and each server handles it its own way — the most common practice is keeping the order they appeared in the header, which is what this page does. If the tie-break matters for your case, do not rely on it: handle the user's preference explicitly.

What does the asterisk at the end mean?

The * is the wildcard matching any language not listed. It usually arrives with a low q, as in "pt-BR,pt;q=0.9,*;q=0.1", and it is the client's way of saying it will take anything if none of its preferences are available.

Can I trust this header to pick the site language?

As an opening default, yes, and it beats guessing from an IP address. But it reflects the operating system configuration, which is not always what the person wants at that moment. The safe route is using the header on the first visit, offering a visible switcher and remembering the choice.

Related Tools

🔤

Accept-Charset Header Parser

Breaks an Accept-Charset header into charsets and q-values and ranks them by preference. The header is deprecated; today's clients simply assume UTF-8.

🗜️

Accept-Encoding Header Parser

Splits an HTTP request header such as gzip, deflate, br;q=1.0 into codings ranked by q value, assuming q=1 whenever the parameter is missing.

🏷️

ETag Weak vs Strong

Reads an ETag header value and says whether it is weak, carrying the W/ prefix and meaning semantic equivalence, or strong, meaning byte-for-byte equality.

⏰

Cache-Control max-age Explained

Convert the Cache-Control max-age value (in seconds) into a readable time in hours and days. Useful for understanding and debugging HTTP cache and CDNs.

🌐

HTTP Request Builder

Build an HTTP request (URL, method, headers, body) and generate snippets in cURL, fetch, axios, Python requests and Go net/http. Everything in your browser.

🤝

HTTP Accept Header Content Negotiation Matcher

Paste a client Accept header and the comma-separated media types a server offers to see which one wins and at what q value. Exact types and */* only.