Why Write ≪Script Type="Text/JavaScript"≫ When the Mime Type Is Set by the Server

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

Douglas Crockford says:


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.

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.

What are modern uses of script type=text/html and is this example considered good use?

According to the HTML5 spec for the script tag, it's totally fine to use <script> with a type attribute set to any valid MIME type. That includes MIME types like text/html or text/plain.

According to the HTML4 spec for the script tag, it's not quite fine:

"There are two types of scripts authors may attach to an HTML
document: Those that are executed one time when the document is loaded
[and t]hose that are executed every time a specific event occurs"

You don't need backbone for templating. You can use e.g. jQuery or my personal favorite, Mustache.js.

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.

Difference between application/x-javascript and text/javascript content types

text/javascript is obsolete, and application/x-javascript was experimental (hence the x- prefix) for a transitional period until application/javascript could be standardised.

You should use application/javascript. This is documented in the RFC.

As far a browsers are concerned, there is no difference (at least in HTTP headers). This was just a change so that the text/* and application/* MIME type groups had a consistent meaning where possible. (text/* MIME types are intended for human readable content, JavaScript is not designed to directly convey meaning to humans).

Note that using application/javascript in the type attribute of a script element will cause the script to be ignored (as being in an unknown language) in some older browsers. Either continue to use text/javascript there or omit the attribute entirely (which is permitted in HTML 5).

This isn't a problem in HTTP headers as browsers universally (as far as I'm aware) either ignore the HTTP content-type of scripts entirely, or are modern enough to recognise application/javascript.

Should I include type=text/javascript in my SCRIPT tags?

You misunderstood what Crockford meant, he didn't say the type attribute is completely invalid, it's just that it's incorrect. The MIME type for JavaScript is application/javascript (or application/ecmascript I can't remember right now).

The general usage though is that is text/javascript which browsers will handle without any problems as that's been the defacto standard for a long time.

In regards to the <script src="..." tag it is redundant because the server determines the MIME type of the file and that is what the browser will then deal with.

He best explains it in one of his videos on YUI Theater (http://developer.yahoo.com/yui/theater/). I don't remember exactly which one he talks about this, I think it was in the advanced JavaScript series (but yeah I've watched them all a few times so they kind of blur into each other).

So if you want to write valid XHTML you need to provide something like text/javascript but it's not the official MIME type of the JavaScript language.

MIME type ('text/html') is not a supported stylesheet MIME type

I'm adding a second answer because I think there could be a different issue. I think the MIME Type error could be due to the css path not being correct. I think it is trying to serve up an error instead of the css file which is not matching the MIME type. Try removing the following line from your HTML Template and allowing the HtmlWebPackPlugin to inject it automatically.

<link rel="stylesheet" href="./style.css" />

Below is my own webpack.config and index.html template which I hope will help.


const MiniCssExtractPlugin = require("mini-css-extract-plugin");
const HtmlWebpackPlugin = require('html-webpack-plugin');
const LinkTypePlugin = require('html-webpack-link-type-plugin').HtmlWebpackLinkTypePlugin;
const CopyPlugin = require('copy-webpack-plugin');

module.exports = {
entry: './src/index.tsx',
output: {
filename: 'app/main.js'
devServer: {
contentBase: './',
watchContentBase: true
module: {
rules: [
test: /\.scss$/,
use: [{
loader: MiniCssExtractPlugin.loader,
options: {

loader: "sass-loader?sourceMap",
options: {
includePaths: [
sourceMap: true
exclude: /node_modules/
test: /\.tsx?$/,
use: {
loader: 'babel-loader'
exclude: /node_modules/
test: /\.(eot|svg|ttf|woff|woff2)$/,
loader: 'file-loader',
options: {
publicPath: "./",
outputPath: "app"
resolve: {
extensions: ['.tsx', '.ts', '.js']
plugins: [
new MiniCssExtractPlugin({
filename: './app/style.css',
new HtmlWebpackPlugin({
template: 'index.html'
new LinkTypePlugin({
'**/*.css' : 'text/css'
new CopyPlugin([
{ from: 'assets', to: 'assets' }


<!DOCTYPE html>

<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<title>My Site</title>
<meta name="viewport" content="width=device-width, initial-scale=1">

<div id="home_container">


Is the 'type' attribute necessary for <script> tags?

For HTML 4.x, the type attribute is required. Source

This attribute specifies the scripting language of the element's contents and overrides the default scripting language. The scripting language is specified as a content type (e.g., "text/javascript"). Authors must supply a value for this attribute. There is no default value for this attribute.

For HTML 5, it is optional. If it is not specified, it defaults to text/javascript. Source

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".

Recommendation: See HTML 5.2

For HTML 5.2, it should be omitted if using a valid JavaScript MIME type (e.g. text/javascript). Source

Omitting the attribute, or setting it to a JavaScript MIME type, 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 charset, async, and defer attributes. Authors should omit the attribute, instead of redundantly giving a JavaScript MIME type.

Related Topics

Leave a reply