The Accept-Language header is an HTTP request header sent by the browser to tell the server which natural languages and locale variants the user prefers. It follows the format defined in RFC 7231, allowing the server to perform content negotiation—serving the most appropriate language version of a webpage to each visitor. For example, a typical Accept-Language header might look like: en-US,en;q=0.9,fr;q=0.7.

The q-value (quality value) ranges from 0.0 to 1.0 and indicates the user's relative preference for each language. A q=1.0 (or no q-value specified) means the highest preference. Lower values like q=0.5 indicate a secondary preference—"I'd accept this language, but only as a fallback." For example, in en-US,en;q=0.9,fr;q=0.5, the user most wants US English, will accept generic English at 90% preference, and will reluctantly accept French at 50% preference if nothing better is available.

Each browser manages language preferences differently:

Chrome: Settings → Languages → Add languages, then drag to reorder by preference.

Firefox: Settings → General → Language → Choose your preferred languages and set the priority order.

Safari: Safari → Preferences → Advanced → Language (or system-level: System Preferences → Language & Region).

Edge: Settings → Languages → Add languages and reorder them. The top language becomes your primary preference with implicit q=1.0.

When a server receives an Accept-Language header, it performs server-driven content negotiation: it compares the user's language preferences against the available translations of the requested resource. The server typically picks the highest q-value language that it supports. If no match is found, it falls back to a default language (often English) or returns a 406 Not Acceptable response. Many web frameworks like Express.js (via accepts library), Django, and ASP.NET have built-in locale negotiation middleware.

If none of the languages in your Accept-Language header match the server's available translations, the server will serve its default language version—usually the site's primary language (often English). Some websites also implement IP-based geolocation as a secondary signal for locale detection. Additionally, many sites use cookies or URL parameters (like ?lang=fr) to let users manually override the negotiated language.

You can test your website's language negotiation by:

1. Using this tool to construct and visualize different Accept-Language headers.

2. Using browser DevTools → Network conditions → override the Accept-Language header manually before making requests.

3. Using cURL with a custom header: curl -H "Accept-Language: fr-CH,fr;q=0.9" https://yoursite.com

4. Browser extensions like "Locale Switcher" that let you quickly switch between language profiles for testing.

en is a macrolanguage tag that matches any English variant, while en-US specifically requests American English. The server's matching algorithm typically treats en as a broader match—it can match en-US, en-GB, en-AU, and any other English locale. In contrast, en-US is more specific and may only match content explicitly tagged as American English. Including both in your Accept-Language (e.g., en-US,en;q=0.9) gives the server flexibility while still expressing your regional preference.

Yes! The wildcard * can be used in Accept-Language to indicate "any language is acceptable." For example: en-US,en;q=0.9,*;q=0.1 means "I strongly prefer English, but I'll accept literally anything else if English isn't available." The wildcard is typically given a very low q-value (like q=0.1) as a last-resort fallback. Without a wildcard, if no languages match, the server may return a 406 Not Acceptable status—though in practice most servers serve a default language instead.

Browsers send multiple languages because most users have graded preferences. You might be fluent in multiple languages at different levels. For instance, a Swiss user might prefer Swiss French (fr-CH), then standard French (fr), then Swiss German (de-CH), and finally accept English (en) as a fallback. Listing multiple languages with descending q-values gives the server the best chance of serving content the user can actually understand, while still respecting their primary preference.

For SEO, Accept-Language plays a role in multilingual and multiregional websites. Google recommends:

• Using separate URLs for different language versions (e.g., /en/, /fr/) with hreflang tags rather than relying solely on Accept-Language negotiation.

• Avoiding automatic redirects based on Accept-Language alone, as this can confuse search engine crawlers and prevent indexing of all language variants.

• Using Accept-Language as a supplementary signal—suggesting a language version to the user while keeping all versions crawlable via clear URL structures and hreflang annotations.