Accept-Language Header for Internet Explorer 7

In addition to the more prominent work we’ve done to enable international scenarios (like adding support for International Domain Names), Internet Explorer 7 updates the available values for the Accept-Language header.  Accept-Language is an HTTP header sent to the server by the browser to indicate the user’s language and locale. 

As an example, the Accept-Language header sent by the browser of a native French speaker in France and fluent in German might be:

Accept-Language: fr-FR,de-DE;q=0.5

A server, upon receiving such a header, should return French content if available, or German content if French content is not available.

By default, the Accept-Language header is calculated based on the Windows default locale, and it can be set on the “Customize your settings” page shown after IE7 is first installed.  Users may specify additional languages using the Internet Control Panel.  To see the list of available language/locales, click the Tools button, then click Internet Options.  On the General tab, click the Languages button to see the Language Preference dialog.  (The languages chosen here are also used to determine which character sets should be displayed natively in the address bar.)

In IE6, most of the choices in the Language Preference list specified a locale-neutral two letter code.  For instance fr was sent for French (France), and ja sent for Japanese.  Longer codes were only used when a language is commonly spoken in another country or locale-- for instance fr-CA was available for French-speaking Canadians.

For Internet Explorer 7, a change was made such that Internet Explorer will send the full language/locale pair for each locale.  IE7 will send fr-FR for French (France) and de-DE for German (Germany).  This change enables web servers to more easily target content for a specific language and locale.  If a given server is only interested in the user’s language and not the locale, it can ignore the locale portion by simply truncating the code at the first dash.

We hope this small change will help web developers on their quest to build ever-smarter web applications.

Eric Lawrence
Program Manager

Edit: replacing Accept-Language=fr-FR,de-DE;q=0.5 with Accept-Language: fr-FR,de-DE;q=0.5

Comments (27)
  1. BTW, IE7 in vista and obiouslly in Windows XP is not displaying well the new design of, I saw it comings from miles away. Maybe you guys didn’t all, because of your lack of Vision.

  2. And that negative behavior of you has what to do with this post about http-headers?

    The guys of the development-team of IE 7.0 are the good guys! There on our side (in my case: of webdeveloping and following W3C-standards). Oké, I admit, that wasn’t always the case in the past, and yes, they still are miles behind other standards-compilant browsers (as FF).

    BUT they did have show a commitmet, they have promissed some things (not unreleastic things, it would be impossible to expect that they correct all the bugs while they have done for 6 years on their browserengine) and maked it true.

    What do we gain from fighting this guys, from bickering them off in every topic because there boses (Billy Gates) don’t think (thought) that upgrading a browser for 6 years is necessary? Nothing.

    We should be happy about the progresses that have been made, instead of staying negative. Always look at the bright side of life…

    Sur, blaim MS… but don’t blaim the IE team. They’re on our side.

    And besides… you can’t expect the IE team that THEY fix alle the x. websites on the internet, don’t you? Still the responsiblity for the webdesigner.

    And BTW… great idee of the language-headers with seperating of the full language and locale var.

  3. Just curiost; what does q=0.5 at the end of the Accept-Language header mean?

  4. Jose says:

    How about £.com €.com Support in IE7?

    Safari and Opera have no issues because they don’t care about the language script encoding. € and £ are on the "Zyyy" (Common)… that’s were the problem is.

    Unicode script language encode zones was decided on India, Pakistan and EUA. Europe was, as usual on things like this, left behind…

    My question is: Would the ie team ever open exceptions on the unicode definitions due to certain languages specific encoding issues (maintaining the phising barrier, of course)?

  5. Henry Boehlert says:

    I applaude this decision. Keep up the good work.

    However, I can’t resist to point out that the locale does make a difference to the language, as en-GB vs. en-US, de-CH vs. de-DE or es-ES vs. es-US.

    Anyway, it’s always more user-friendly to use Accept-Language than IP-address-based Geo-Location.

  6. Henry Boehlert says:


    the q stands for "quality" and denotes a preference where 1 is highest and 0 means "not acceptable".


    The default is 1, so in the case above, the user has a 2:1 preference of French (France) over German (Germany).

    And for example,

    Accept-Language: eo;q=0

    means "I can’t read or understand Esperanto and no, please do not provide any content in that language."

  7. Rijk says:

    In Opera, we found that it is important to also add the ‘neutral’ language tag to the list. We also encountered some problems when beta-testing this for Opera 9 with the Hotmail server, which refused to send content for same locales. Not all servers are set to gracefully handle this header…

  8. EricLaw [MSFT] says:

    @Jose: It’s possible that certain characters will be permitted to mix in a future release of IE.  This depends on a variety of factors, including future standards, the phishing environment, and the user-scenarios that such a change would enable.

    @Henry Boehlert: Yes, this is one of the reasons that we’re starting to provide locale info.

    @Rijk: As a part of our IE7 work, we’ve been working with Microsoft (and other) site owners to ensure that they correctly fall back to the appropriate neutral language if they are not locale-aware.  Please feel to contact me directly (ericlaw at Microsoft) if you encounter sites that need updates.  Thanks!

  9. Nick says:

    Reading IE blog I sometimes get just scared. What kind of developers should MS hire that they make primitive and ignorant tech mistakes in their posts.


    That’s NOT an HTTP header. And if author had ever done something serious on the web, he MUST know HTTP header syntax!

    The correct header should look like this:

    Accept-Language: fr-FR,de-DE;q=0.5

    Just to illustrate the pattern… I recall posting a BMP (!) image about 500Kb in size on this blog before.

    How can such ‘professionals’ produce any sane piece of software?

  10. Kevin says:


    That was not a primitive and ignorant tech mistake… that was a "typo" (sheesh)!

    Of course you’ve -NEVER- made one, right??

  11. The official locations for these codes are available online.


    [*][url=][ISO 639-2] Language Codes[/url]

    [*][url=][ISO 3166] Code Lists[/url]


    These are same codes used the HTML [b]lang[/b] attribute, which can be a bit confusing!


    Indicates the language used for the actual content.


    Indicates suitability for a particular audience but the content [i]may[/i] not even be in this language.

    Nice to see the IE team improving their use of all web standards and not just HTML+CSS.

  12. I think this is going to cause major problems with content negotiation on the Web.

    To give a practical example:

    Set your language settings to just es-MX and/or es-ES and point your browser to

    You’ll get back the English version, even though there’s a Spanish version there. Someone with es-MX and es set in IE6 or Firefox will see the Spanish version automatically.

    This is down to the way language negotiation is done on the Apache server.

    In the article cited above we explain that "Some of the server-side language selection mechanisms require an exact match to the Accept-Language header. If a document on the server is tagged as fr (French) then a request for a document matching fr-CH (Swiss French) will fail. To ensure success you should configure your browser to request both fr-CH and fr."

    Apart from the fact that most users wouldn’t even know that they can set their browser preferences differently, not to mention knowing how to do that, IE7 CR1 doesn’t actually provide a selection for es rather than es-ES – you have to enter it manually.  Not likely to happen much.

    A simple fix to this would be to set the user’s default preferences to *also* include es (ie. fr-FR, fr for France).  Then, when a file such as is not found, the server will find and return a French file.  Those people who want to know where the user’s browser is (likely to be) located can still use the fr-FR information to get the locale.

    I think that the result of ignoring this is that many people will be confused about why they no longer see a page in Spanish, when they did before, and a lot of hard work by content developers will go unnoticed on the Web.  In short, think you are about to introduce a serious bug.

    (Note, in passing, that the rules for specifying the lang attribute in HTML and xml:lang in XHTML are described by BCP47.  The latest syntax specification is RFC4747 – which obsoletes RFC 3066 and RFC 1766, and which tells you to go to the IANA Language Subtag Registry at to find out what language codes to use, rather than the ISO code lists.  For more information, see )

    Hope that helps.

  13. Chris H says:

    Nice to see this in IE. I also like how the q=0.x value is manipulated when added or re-ordering the language preference!

    Can IE 7 make use of the <link rel="alternate" lang="fr-FR" … >* HTML if a web server doesn’t support content language selection? For example, if I had the HTML page in English (page.htm), but also had a French version  (fr-FR-page.htm), and included the following in the English version (page.htm):

    <link rel="alternate" lang="fr-FR" href="fr-FR-page.htm" />*

    … would IE alert the user (perhaps via the info bar) or automatically load the French version if the user preference had French at the top of the language list? If not, could this be considered for IE in future?

    * Sorry if my syntax is incorrect.

    Also, not directly related to this topic, but what benefit does the HTTP Header "UA-CPU: x86" offer? Why would a web site / server need to know the CPU?

    – Chris

  14. milo says:

    Why webmasters has to take care of ie7 now?

    There are enough rules for browsers to show content in the right way, in the last days i stumbled upon several guides how to improve websites for your forthcoming ie 7.

  15. goose says:

    thank u for allowing us to build ever-smarter web  applications!!!!!!!!

  16. Aedrin says:

    "A simple fix to this would be to set the user’s default preferences to *also* include es (ie. fr-FR, fr for France)."

    This is a bug in Apache or in the standard then, and I surely hope IE will not do this.

    The proper way would be:

    – Check for exact match [es-MX]

    – If not found, match [es]

    "Why webmasters has to take care of ie7 now?

    There are enough rules for browsers to show content in the right way, in the last days i stumbled upon several guides how to improve websites for your forthcoming ie 7."

    They don’t. You could just develop for your own browser and ignore what people will be using. Besides, this is either part of your job or your hobby. It’s really not that much work if you educate yourself.

  17. c says:

    "Also, not directly related to this topic, but what benefit does the HTTP Header "UA-CPU: x86" offer? Why would a web site / server need to know the CPU?"

    So that the page could, for example, reference the x86 or x64 version of an ActiveX control, or a download site could automatically redirect you to the x64 version of an application.  Or so a site would know that your OS doesn’t allow kernel patching so it would skip over that exploit.

  18. EricLaw [MSFT] says:

    @Nick: The string in question is reformatted by the ASP engine when displayed back to the user from an echo trace page.

    You’re correct in noting that I could have simply copied the exact header bytes out of the Fiddler HTTP Debugger (which I wrote, btw) and the copied text would not replace the : with an = sign.

    I’m sorry if you were confused.

  19. Keith Knutsson says:

    Interesting comments on the topic. Thank you guys for sharing.


    Keith Knutsson

  20. Jose says:

    Thanks for your reply EricLaw. I have created a "Mixed Characters request to Microsoft" on one of the most well known IDN domains forum, so that people can discuss this. Thanks.

  21. manabu says:

    how does this "Accept-Language" header work with "language preference" in IE menu/tools/internet options…/general/languages?

    who has higher priority, or they are for different purposes?

  22. kL says:

    BTW: any plans to fix the Accept: header? The one used for MIME types? Currently it sends */*, which isn’t useful for content negotiation.

  23. (Sorry guys, temptation of answering to some of these useless comments sometimes is so powerful…)

    @milo asked "Why webmasters has to take care of ie7 now?"…

    Because "webmasters" might be using some nasty CSS hacks all over their precious websites?

    Or because "webmasters" might be those individuals who have enjoyed designing structurally overblown and outwardly spunky websites by using any non-standard ways that we can actually think of, so they had to take care of all available browsers and their quirks and flaws? Well, in this case they can rest assured; they’ll have another browser to enjoy taking care of.

    If our hypothetical "webmasters" are none of the above then no worries. IE7 will be going to take care of *some* of its predecessor’s shortcomings…


  24. EricLaw [MSFT] says:

    @manabu: The "Language Preference" dialog sets the Accept-Language header.

    @kL: There are no plans for changes to the Accept header for IE7.  This is something that may be addressed in IE8.

  25. Benjamin Hawkes-Lewis says:

    First, it’s great to see the IE team trying to make more use of existing web standards. But can anyone explain why the expected treatment of Accept-Language header here differs so wildly from the HTTP specification:

    It is the job of the requesting client, not the responding server, to indicate that (for example) while fr-fr (French French) is best, any French is still preferred over other languages. Hence, Firefox uses headers like "fr-fr,fr;q=0.5", Opera uses "fr-FR,fr,q=0.9", and Konqueror (like the old IE) uses "fr".

    One cannot trust an Accept header that does not declare an explicit preference for HTML or XHTML, because IE’s Accept header fails to do so, even though IE does not even try to render XHTML. So server and web developers are forced to check either for an explicit inclusion of application/xhtml+xml in the Accept header or for particular rendering engines in the User-Agent header. The modification of browsers’ native feature-set by extensions such as MathPlayer 2.0 makes this process extremely perilous.

    IE’s failure to either comply with the spec or even mimic other browsers will force developers to hack around Microsoft’s non-compliance. Amazingly the post presents this as some sort of bonus: "This change enables web servers to more easily target content for a specific language and locale.  If a given server is only interested in the user’s language and not the locale, it can ignore the locale portion by simply truncating the code at the first dash." Say what? It is even more astonishing to see this deviant behaviour instantly being described by a commentator like Aedrin as the "proper way" ( ) it should be done!

    Also, only the requesting client can clarify that if its preferred languages are not available it would still like content in other languages: that’s why there’s a language wildcard (*). The specification states: "If no language-range in the field matches the tag, the language quality factor assigned is 0. … If an Accept-Language header is present, then all languages which are assigned a quality factor greater than 0 are acceptable."

    So if you receive a request for "fr-fr,fr;q=0.9" alone and you only have content in German, then your best guess (if browsers developers actually paid attention to the specs) would be to respond with 406 No Content. (I hasten to add that the spec fortunately does give servers the leeway to respond pretty much however they deem necessary.)

    Not sending a wildcard has, appropriately, been marked as a Mozilla bug:

    IE (and the other browsers too) should be producing Accept-Language headers more like:

    Accept-Language: fr-fr,fr;q=0.9,*;q=0.8

  26. Shinjiman says:

    No idea some language tags like ‘zh-Hans’ or ‘zh-Hant’ are accepted in the Internet Explorer 7, since the Internet Explorer 6 does not supported them. (see and the RFC 4646 for more details.)

  27. While your at it, does IE7 support accept-content-type? ‘cos *that* would be useful.

Comments are closed.

Skip to main content