When to use the JavaScript MIME type application/javascript instead of text/javascript?

Question

Based on the question jQuery code not working in IE, text/javascript is used in HTML documents so Internet Explorer can understand it.

But I’m wondering, when would you use application/javascript, and more importantly, why would you use it instead of text/javascript?

• Benn: possible dupe/explanation: stackoverflow.com/questions/876561/…
• Gumbo: See also stackoverflow.com/questions/2325571/…
• Bergi: possible duplicate of What is the Javascript MIME Type? What belongs in the type attribute of a script tag?
• Chuck Le Butt: Possible duplicate of When serving JavaScript files, is it better to use the application/javascript or application/x-javascript

Answer 1

In theory, according to RFC 4329, application/javascript.

The reason it is supposed to be application is not anything to do with whether the type is readable or executable. It's because there are custom charset-determination mechanisms laid down by the language/type itself, rather than just the generic charset parameter. A subtype of text should be capable of being transcoded by a proxy to another charset, changing the charset parameter. This is not true of JavaScript because:

a. the RFC says user-agents should be doing BOM-sniffing on the script to determine type (I'm not sure if any browsers actually do this though);

b. browsers use other information—the including page's encoding and in some browsers the script charset attribute—to determine the charset. So any proxy that tried to transcode the resource would break its users. (Of course in reality no-one ever uses transcoding proxies anyway, but that was the intent.)

Therefore the exact bytes of the file must be preserved exactly, which makes it a binary application type and not technically character-based text.

For the same reason, application/xml is officially preferred over text/xml: XML has its own in-band charset signalling mechanisms. And everyone ignores application for XML, too.

text/javascript and text/xml may not be the official Right Thing, but there are what everyone uses today for compatibility reasons, and the reasons why they're not the right thing are practically speaking completely unimportant.

• Pacerier: The most "compatibility" solution is not to include any content type in the response at all. RFC states that without an explicit content type, the receiver would interpret it "by context" which is always the correct behavior for all browsers right from the very first browsers
• Joscha: Be careful with application/javascript and IE running on compatibility mode with IE=8. Seems as if inline scripts are not properly evaluated. text/javascript works fine there.
• sammy_winter: @Pacerier - I know this comment is 5 years old, but today it is often best to include mime types, particularly for forum type websites, for security reasons. Having the receiver interpret the type leaves one open to attack by uploading a malicious javascript file as an image, and then having the browser interpret and run that script. It is better to have the server return mime types for all responses and use the header X-Content-Type-Options: nosniff to prevent the browser from interpreting the type.
• user11877195: @sammy_winter I see warnings like these everywhere and cringe every time. If I allowed users to upload content, I'd probably do more validation than "oh yeah, name matched regex for png file, I can trust that", wouldn't I? If incorrect header becomes a "security issue", the problem is maybe somewhere deeper, don't you think? This is the same as with hiding Server: nginx or whatever nginx sends. As if whoever is capable of finding a hole needs explicit header to know what server you run...
• sengi: The WHATWG HTML standard seems to disagree with the IETF as to which MIME type should be used. html.spec.whatwg.org/#scriptingLanguages But it doesn't matter in practice because of mimesniff.spec.whatwg.org/#javascript-mime-type

Answer 2

The problem with Javascript's MIME type is that there hasn't been a standard for years. Now we've got application/javascript as an official MIME type.

But actually, the MIME type doesn't matter at all, as the browser can determine the type itself. That's why the HTML5 specs state that the type="text/javascript" is no longer required.

Answer 3

There's been a lot of confusion and disagreement about this in the past, which other answers explain in some detail.

RFC9239 finally resolves this confusion by aligning with implementation reality. application/javascript is now officially obsolete; text/javascript is the only correct JavaScript MIME type.

• YudhiWidyatama: RFC4239 which are released April 2006 states text/javascript is obsolete, and the application/javascript is the way to go. But RFC9239 states the other way around. Since RFC9239 dated May 2022, it supposedly the one we adopt now, but these information got me confused at first :D

Answer 4

application because .js-Files aren't something a user wants to read but something that should get executed.

• Benn: That's the official answer but IE chokes on it.
• thejh: @Benn: Maybe because IE users have to read all the JS files because they don't execute properly? At least, it's honest by Microsoft ;)
• Mark Baijens: Love your comment, but unfortunately people who can't read javascript still use IE so we have to deal with it :(.
• Zenexer: I don't think whether or not you want to read it has anything to do with why. It has to do with how the data gets transcoded--or rather, whether it can be.
• user4244405: technically, HTML and CSS are also "executed" (parsed) by the browser to produce the result of the code as visual content and is not meant for the user to "read" it, so, this answer does not make much sense. I guess there is major confusion as to what is "text" and what is "application". If i could vote in this matter, i'd say the IETF should consider "text" contents as text, and binary as either application -OR the "purpose" of said type as in "image", or "document", etc.

Answer 5

application/javascript is the correct type to use but since it's not supported by IE6-8 you're going to be stuck with text/javascript. If you don't care about validity (HTML5 excluded) then just don't specify a type.

• Zenexer: Where'd you get this? I'm pretty sure it's supported. Or, at least, it will be ignored.
• Camilo Martin: @Zenexer read his answer to another question. Seemingly IE compatibility means no application/javascript.
• Zenexer: @CamiloMartin I use it fine with IE down to 6 all of the time. They just default to JavaScript.
• Camilo Martin: @Zenexer Hm, strange. I wonder what was the problem about in the other Q&A.
• Radu: @Zenexer It's been a while since I've had to deal with this but here are some other accounts of this causing issues with IE6-8. Not entirely sure why this only seems to matter some times but in my experience it has caused issues.