text/javascript JavaScript Flagship

What it's for

The MIME type for JavaScript source files has an unusually messy history worth knowing explicitly: application/javascript was the officially registered type for years, but the WHATWG HTML spec and current guidance now recommend text/javascript instead — a rare case where "what the spec says" changed direction rather than a new type simply being added. As of RFC 9239 (2022), text/javascript is the IANA-registered, currently correct type; application/javascript is deprecated but still extremely widely seen in the wild and still functionally works in every browser.

If you're setting this header yourself (serving .js files from a custom server, generating dynamic scripts), use text/javascript today. If you inherited code or configuration using application/javascript, it's not broken, but it's worth knowing it's the outdated form.

Format & syntax

Content-Type: text/javascript
Content-Type: text/javascript; charset=utf-8

No structural rules beyond "valid JavaScript source code" — the MIME type itself doesn't distinguish between script versions, module vs. classic scripts, or any JS-specific syntax variant; that distinction is made separately via the <script type="module"> attribute in HTML, unrelated to the HTTP Content-Type header.

How it's used in practice

• Serving .js files from web servers — most static file servers (Nginx, Apache, CDNs) have this MIME mapping built in already and will serve .js files correctly without any manual configuration; this reference matters most when you're configuring a custom server, writing middleware, or debugging why a script isn't executing.
• <script> tag execution requirements — browsers check the Content-Type of a script resource against a list of "JavaScript MIME types" before executing it; both text/javascript and application/javascript (among a few other historical variants) are accepted, so this particular header choice doesn't currently break execution either way, though following current spec guidance is still the recommended practice.
• ES module imports — import statements and <script type="module"> still rely on the server sending a JavaScript-recognized Content-Type; getting this wrong (e.g., serving .js as text/plain) is a common cause of "module scripts are only supported via HTTPS or a JavaScript MIME type" console errors.
• Dynamically generated scripts — API endpoints or SSR frameworks that generate JavaScript on the fly (rather than serving static files) need to set this header explicitly, since there's no file-extension-based auto-detection happening for a dynamically generated response.

Common mistakes & gotchas

• Serving .js files with the wrong Content-Type entirely — most commonly text/plain or application/octet-stream from a misconfigured custom server or storage bucket (like a cloud storage service that doesn't auto-detect JS files correctly) — this will cause browsers to refuse to execute the script as a module, or in strict-MIME-checking contexts, refuse to run it at all.
• Confusing the browser's leniency with correctness — because browsers currently accept several JS-related MIME types for backward compatibility (application/javascript, application/x-javascript, text/javascript, and a few others), it's easy to not notice you're using an outdated type since nothing visibly breaks — but following current spec (text/javascript) is still the better practice going forward.
• Module scripts having stricter requirements than classic scripts in some contexts — certain strict-MIME-type-checking scenarios (some service worker contexts, for example) are less forgiving about non-standard JavaScript MIME types than a typical <script> tag, making it worth using the currently correct type rather than relying on broad but not-guaranteed-forever browser leniency.
• CDN or storage provider serving the wrong type for uploaded JS files — cloud storage services sometimes default to application/octet-stream for uploaded files unless you explicitly set the Content-Type at upload time, which is a common gotcha when self-hosting JS assets on object storage rather than a traditional web server.

Comparison & FAQ

Should I use text/javascript or application/javascript?

Use text/javascript — it's the currently correct, IANA-registered type per RFC 9239. application/javascript still works in every browser for backward compatibility but is considered deprecated.

Will my scripts break if I'm still using application/javascript?

Not currently — browsers still accept it for backward compatibility. But it's worth updating to text/javascript when you have the chance, since it's the spec-correct form going forward and there's no guarantee of indefinite leniency.

Why is my ES module import failing with a MIME type error?

Check that your server is actually sending a JavaScript-recognized Content-Type (text/javascript or the older application/javascript) for the .js file — a common cause is a custom server or storage bucket defaulting to text/plain or application/octet-stream instead.

Does the MIME type affect whether a script runs as a module vs. a classic script?

No — that distinction is controlled by the type="module" attribute on the <script> tag in HTML, completely separate from the HTTP Content-Type header, which only needs to be a recognized JavaScript MIME type either way.