107

The whole question fits in the title. And to add some context: I'm not asking what is the best according to what the specs are saying, but rather what works the best given the mix of browsers deployed nowadays.

Some data points:

  • Google uses text/javascript for the JS used on their home page.
  • Google uses text/javascript on Google Docs.
  • Google uses application/x-javascript to serve JavaScript files with their Ajax libraries service.
  • Yahoo uses application/x-javascript to serve their JS.
  • Yahoo uses application/x-javascript for the JavaScript served on their home page.
3
  • 4
    Funny. You give a third alternative in your examples... And according to Tim, both big players are wrong (with regard to standards), which probably only mean browsers are tolerant (no big news here) and it might no matter.
    – PhiLho
    Commented May 18, 2009 at 8:28
  • 1
    possible dupe: Javascript MIME Type
    – Bergi
    Commented Aug 28, 2013 at 20:48
  • The answers to this question here and elsewhere are ambiguous. A programmer is expected to cross her fingers and hope for the best. Commented Jul 12, 2021 at 13:05

6 Answers 6

134

According to the IETF's ECMAScript Media Types Updates as of 22 February 2021, the RFC-4329 is obsolete.

Therefore:

  • text/javascript is a recommended standard (both by IETF and by MDN)
  • application/x-javascript was experimental while deciding to move to…
  • application/javascript is obsolete
9
  • 3
    This question from a few months ago says the exact opposite. Someone is mistaken :) "Kelly's right, browsers tend to trust the MIME type sent with the response headers over the type attribute of the script tag" stackoverflow.com/questions/189850/…
    – Marco
    Commented Aug 14, 2009 at 17:46
  • 6
    Oh no! Big, monolithic, slow organisations must be right! The spec must be wrong! Narghh. I'll continue to trust the specification and my own experience over large (slow) companies, even if one of them used to employ me.
    – Quentin
    Commented Dec 7, 2012 at 20:11
  • 1
    Hmm, someone forgot to tell W3C that text/javascript is obsolete. It seems to be the default in HTML 5. ::scratches head:: It also seems (if my cursory reading of this section is correct) that user agents are supposed to go only on the type attribute, thus ignoring the Content-type would be correct behavior.
    – big_m
    Commented Feb 10, 2013 at 1:35
  • 1
    @big_m — That's because lots of browsers don't recognise application/javascript so specifying it will cause them to ignore the script. User agents aren't supposed to ignore the Content-Type. The type attribute tells them what to expect. If they don't support it, they shouldn't bother to request it. If the server then says it is something different, they should go on that rather then what the HTML says (at least according to HTTP, you might be looking at a different spec, you didn't provide any links).
    – Quentin
    Commented Feb 10, 2013 at 1:46
  • 1
    @Quentin, I was referring to the HTML 5 section on the script element, that I linked to. My read of that section is different from what you describe; it seems to put a lot of importance on the type attribute and makes no mention of checking the Content-Type, except for determining the character encoding. I agree that it seems like it would be wise for the user agent to verify that the Content-Type matches what is expected, but I haven't found anything in the HTML spec that requires or even recommends doing that.
    – big_m
    Commented Feb 10, 2013 at 2:57
14

Here's the 2020 answer to this question.

text/javascript is the correct JavaScript MIME type per the HTML Standard, which states:

Servers should use text/javascript for JavaScript resources. Servers should not use other JavaScript MIME types for JavaScript resources, and must not use non-JavaScript MIME types.

And also:

[…] the MIME type used to refer to JavaScript in this specification is text/javascript, since that is the most commonly used type, despite it being an officially obsoleted type according to RFC 4329.

Work is underway to reflect this reality in an RFC at the IETF level: https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/

Any claim that "text/javascript is the obsolete one" is saying so based on RFC 4329, which both the HTML Standard and the abovementioned IETF draft (i.e. an upcoming RFC) are explicitly correcting.

0
12

In most situations, the mime type the server sends makes no practical difference. I would go with application/javascript, which is also recommended by an RFC.

0
8

It used to be language="javacript". Then it changed to type="text/javascript". Now it is type="application/javacript". Ok this is getting dumb. Some of the older browsers don't recognize the new application/javascript, but still recognize the older text/javascript. I plan to continue using this, or else I'll waste hours of my time trying to change EVERY instance of text/javascript into application/javascript.
Now some day the opposite might be true. Some day the newest browsers might reject the old technique in order to be strictly standard's compliant.
But until people viewing my website start complaining that "ever since upgrading my browser, about 50% of your website disappeared", I have no motive to change the code in my website.

1
7

If you choose to use application/javascript for js in your pages, IE7 and IE8 will not run your script! Blame Microsoft all you want, but if you want most people to run your pages use text/javascript.

1
  • 3
    When you say that "application/javascript" will not work, do you mean if that is set as the content type on the HTTP response or as the "type" attribute of a script tag? The original question was on content type on HTTP responses. Based on other answers it looks like only the value of the "type" attribute on script tags will make a difference either way in IE. Commented Jun 16, 2011 at 18:03
4

It has been "text/javascript" but this is obsolete (see the IANA List) and now it should be "application/javascript" (see another IANA List).

Not the answer you're looking for? Browse other questions tagged or ask your own question.