What Is the JavaScript Mime Type for the Type Attribute of a Script Tag

What is the javascript MIME type for the type attribute of a script tag?

This is a common mistake. The MIME type for javascript wasn't standardized for years. It's now officially: "application/javascript".

The real kicker here is that most browsers won't use that attribute anyway, at least not in the case of the script tag. They actually peek inside the packet and determine the type for themselves.

So the bottom line is that the type="text/javascript" doesn't do anything as far as the javascript is concerned, but it's part of the spec for both HTML 4 and XHTML 1.0.

Why write script type=text/javascript when the mime type is set by the server?

Douglas Crockford says:

type="text/javascript"

This attribute is optional. Since
Netscape 2, the default programming
language in all browsers has been
JavaScript. In XHTML, this attribute
is required and unnecessary. In HTML,
it is better to leave it out. The
browser knows what to do.

He also says:

W3C did not adopt the language
attribute, favoring instead a type
attribute which takes a MIME type.
Unfortunately, the MIME type was not
standardized, so it is sometimes
"text/javascript" or
"application/ecmascript" or something
else. Fortunately, all browsers will
always choose JavaScript as the
default programming language, so it is
always best to simply write <script>.
It is smallest, and it works on the
most browsers.

For entertainment purposes only, I tried out the following five scripts

  <script type="application/ecmascript">alert("1");</script>
  <script type="text/javascript">alert("2");</script>
  <script type="baloney">alert("3");</script>
  <script type="">alert("4");</script>
  <script >alert("5");</script>

On Chrome, all but script 3 (type="baloney") worked. IE8 did not run script 1 (type="application/ecmascript") or script 3. Based on my non-extensive sample of two browsers, it looks like you can safely ignore the type attribute, but that it you use it you better use a legal (browser dependent) value.

Is there any useful mime for script type=mime src=... except for JS?

Not particularly, unless you have a .json file and the server sends the appropriate MIME type in the response header. Otherwise, the contents of the <script> tag will not be processed.

Per the WHATWG specification,

The type attribute allows customization of the type of script represented:
Omitting the attribute, setting it to the empty string, or setting it to a JavaScript MIME type essence match, means that the script is a classic script, to be interpreted according to the JavaScript Script top-level production. Classic scripts are affected by the async and defer attributes, but only when the src attribute is set. Authors should omit the type attribute instead of redundantly setting it.
Setting the attribute to an ASCII case-insensitive match for the string "module" means that the script is a module script. If it has a JavaScript MIME type, or if the script is embedded inline, then it will be interpreted as a JavaScript module script according to the JavaScript Module top-level production; if it has a JSON MIME type, then it will be interpreted as a JSON module script. Module scripts are not affected by the defer attribute, but are affected by the async attribute (regardless of the state of the src attribute).
Setting the attribute to any other value means that the script is a data block, which is not processed. None of the script attributes (except type itself) have any effect on data blocks. Authors must use a valid MIME type string that is not a JavaScript MIME type essence match to denote data blocks.

A JavaScript MIME is defined as any of the following:

application/ecmascript
application/javascript
application/x-ecmascript
application/x-javascript
text/ecmascript
text/javascript
text/javascript1.0
text/javascript1.1
text/javascript1.2
text/javascript1.3
text/javascript1.4
text/javascript1.5
text/jscript
text/livescript
text/x-ecmascript
text/x-javascript

A JSON MIME is defined as

any MIME type whose subtype ends in "+json" or whose essence is "application/json" or "text/json".

It is important to note that you must use a valid MIME type in order to guarantee browsers will never try to process it. Otherwise, future additions to the specification could break your code:

The requirement that data blocks must be denoted using a valid MIME type string is in place to avoid potential future collisions. If this specification ever adds additional types of script, they will be triggered by setting the type attribute to something which is not a MIME type, like how the "module" value denotes module scripts. By using a valid MIME type string now, you ensure that your data block will not ever be reinterpreted as a different script type, even in future user agents.

A valid MIME type is defined by the WHATWG here.

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

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.

Javascript MIME

Officially, IANA (keepers of the official MIME type registry) lists text/javascript and text/ecmascript as obsolete (via RFC 4329).

Of those two, it easiest to use application/javascript. The use of application/ecmascript brings with it stricter character encoding requirements and less forgiving error handling as specified in 4329.

Practically, you have to use text/javascript if you want it to work in IE.

Also, my recommendation is to skip the type attribute of <script> tags entirely. Every browser will run your JS just fine without. (You still need to serve .js files with a HTTP Content-Type of text/javascript, though.)

JavaScript ES6 Modules MIME Type

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/

text/javascript vs application/javascript

Per IETF RFC 9239 text/javascript is now standard and application/javascript is now considered obsolete.

The media type registrations herein are divided into two major categories: (1) the sole media type
"text/javascript", which is now in common usage and (2) all of the media types that are obsolete
(i.e., "application/ecmascript", "application/javascript", "application/x-ecmascript", "application/
x-javascript", "text/ecmascript", "text/javascript1.0", "text/javascript1.1", "text/javascript1.2", "text/
javascript1.3", "text/javascript1.4", "text/javascript1.5", "text/jscript", "text/livescript", and "text/xecmascript").

See further notes in When serving JavaScript files, is it better to use the application/javascript or application/x-javascript

Understanding the type attribute in a script tag

I want to understand the magic behind adding type='text/babel' to a script tag.

No real magic: The Babel script you include on the page looks for those elements and transpiles them into ES5 on-the-fly, then has the browser run the resulting ES5 code. Setting that type on the script elements does two things:

Prevents the browser from trying to run them directly, and
Identifies them for the Babel script.

Regarding type on script in general, from the specification:

The type attribute gives the language of the script or format of the data. If the attribute is present, its value must be a valid MIME type. The charset parameter must not be specified. The default, which is used if the attribute is absent, is "text/javascript".

Then later when explaining how to process script elements:

If the user agent does not support the scripting language given by the script block's type for this script element, then the user agent must abort these steps at this point. The script is not executed.

It's worth calling out what the Babel website says about transpiling in the browser:

Compiling in the browser has a fairly limited use case, so if you are working on a production site you should be precompiling your scripts server-side. See setup build systems for more information.

(Where they've said "compiling" most of us would say "transpiling.")

Why do javascript tags use text?

Because it is. Javascript source is text. This predicate will determine how the data is transported. Then, the type of text (Javascript source) determines how it is used.

script type=text/javascript Resource interpreted as Other but transferred with MIME type undefined

The MIME-Type of the file is set by the server. For JS files a MIME-Type of text/javascript should be returned. It's not doing this here, that's why you get the notice.

The language property in <script> is deprecated.

<script type="text/javascript">

is correct.

Also see: What is the difference between "lang" and "type" attributes in a script tag?

The MIME-type is a header the server sends along with any file that is requested. The client is free to ignore it of course. Usually if your file is a *.js file your webserver will select the right MIME-type for you, if your file is a .jsp script that returns a JavaScripts file then you will likely need to set the MIME-type header yourself, this is fairly trivial in most languages, I wouldn't know how to do it in JSP but in PHP it's: header("MIME-Type: text/javascript"); anywhere before you start echo'ing the actual content.

What Is the JavaScript Mime Type for the Type Attribute of a Script Tag