Deprecated MIME Types and Their Modern Replacements

Deprecated MIME Types and Their Modern Replacements

Several MIME types have been formally superseded and should not appear in new configuration. The process of MIME type deprecation happens through IANA registration updates and IETF RFCs that designate existing types as obsolete and specify replacements. Browsers maintain backwards compatibility with deprecated types to avoid breaking the existing web, which can create a false sense that the old types are still acceptable to use. In practice, serving deprecated types signals outdated server configuration to auditing tools, may trigger warnings in future browser releases, and in some cases causes failures with strict CSP configurations. The most commonly encountered superseded types are application/javascript and application/ecmascript (the IANA registry now lists text/javascript as the preferred JavaScript type per RFC 9239),¹ text/xml (an alias for application/xml per RFC 7303), image/x-icon (a pre-standard type replaced by the IANA-registered image/vnd.microsoft.icon), and application/vnd.ms-fontobject (EOT fonts, effectively deprecated with IE end-of-life).

Why MIME type deprecations happen in IANA registrations

IANA maintains the official registry of MIME types. When a type is registered, it goes through a review process that establishes the type string, the format specification reference, and any security considerations. Over time, specifications evolve: better formats replace older ones, formal RFC processes establish correct type strings for previously informally registered types, and security research reveals problems with existing registrations. RFC 9239 for JavaScript and RFC 7303 for XML are examples of RFCs that formalise the correct types after years of ambiguity in deployed content.²

Deprecation does not mean the type stops working

The deprecated types remain in the IANA registry as historical records with notes pointing to their replacements. Browsers maintain compatibility with deprecated types indefinitely because breaking existing content would harm user experience. Consequently, deprecation in IANA does not mean the type stops working; it means the type is not the recommended choice for new configurations. Updating deprecated types in your server configuration is a low-effort change that signals current hygiene to security auditing tools and eliminates a class of warnings that can obscure more serious issues in your header configuration.

Real-world risk of serving deprecated types

Serving application/javascript instead of the IANA-preferred text/javascript (per RFC 9239 backwards-compatibility guidance) carries no practical risk in current browsers, since all modern browsers treat both as equivalent. The risk is future-oriented: browser vendors may increase CSP strictness, add deprecation warnings to developer tools, or eventually enforce the registered type as the only valid script MIME type. Serving image/x-icon rather than image/vnd.microsoft.icon is similarly low-risk but detectable in MIME auditing tools as a configuration issue.³ Furthermore, auditing tools like Mozilla HTTP Observatory and custom header-checking scripts flag deprecated MIME types as configuration issues that lower scores. Building on this, the practical motivation for updating deprecated types is primarily about passing audits and demonstrating current configuration hygiene, rather than fixing an active browser failure.

How to audit your server for deprecated types

Finding deprecated MIME types in a server configuration requires checking both the configuration files and the actual HTTP responses. Start with the configuration files: grep for deprecated type strings in mime.types, httpd.conf, .htaccess files, and Caddy configuration. Running grep -r "application/ecmascript" /etc/nginx/ finds any hardcoded deprecated type in Nginx configuration. Next, verify the actual HTTP responses with curl spot-checks. Run curl -sI https://your-domain.com/script.js and confirm the Content-Type matches the expected value.⁴ For systematic auditing across many file types, automate curl calls for a representative URL of each file type and compare the responses against an expected-type map. Furthermore, browser Network panel inspection during a site visit captures all Content-Type values in use during a real page load, revealing types served by third-party resources that configuration audits cannot reach.

Deprecated audio and video MIME types and their replacements

Audio and video MIME types accumulated legacy x- prefixed variants before standardisation. audio/x-mpeg predates the IANA registration of audio/mpeg and remains recognised by some older media players while being absent from modern browser documentation. audio/x-wav and audio/x-ogg similarly predate their standardised counterparts audio/wav and audio/ogg. Serving audio files with these x- prefixed types works across most current browsers, but switching to the registered types makes intent explicit and avoids confusion during server audits.

Video formats carried the same pattern. video/x-ogg predates video/ogg, and video/x-ms-wmv was a Microsoft-specific type before the broader adoption of container-agnostic identifiers. Neither x-prefixed video type appears in the IANA media type registry. For servers still sending these legacy video types, updating to video/ogg or video/webm for open-format content removes the ambiguity and aligns with HTTP header auditing tools that flag unregistered types.

Replacing deprecated image types in server configuration

image/x-png was a common MIME type before image/png received its IANA registration in 1996,⁵ and some legacy server configurations still map .png files to image/x-png even though browsers parse both identically without any rendering difference. The practical impact is that image/x-png produces lint warnings in HTTP header auditing tools and lowers your security score without affecting actual browser behaviour. For Apache, a single AddType image/png .png directive corrects this. For Nginx, adding image/png png; to the types block achieves the same result, and running nginx -t before reloading confirms the syntax is valid.

Integrating MIME type auditing into CI pipelines

Automating MIME type checks prevents configuration regressions from reaching production. A post-deployment smoke test can issue curl -sI requests to a representative set of file types and compare the Content-Type response headers against an expected list. Storing the expected list as a YAML or JSON fixture in the repository makes diffs visible in code review when expected types change intentionally.

GitHub Actions can run this smoke test in a job that triggers after the deployment step.⁶ A simple bash script iterates over an array of URLs, extracts the Content-Type header with grep -i "content-type:", and exits with status 1 if the value does not match the expected string. An exit status of 1 causes the GitHub Actions job to fail, blocking merges that would deploy a MIME-misconfigured server.

Auditing application/wasm and font MIME types in CI

WebAssembly and web font MIME types are the most commonly misconfigured formats in CI environments because they were added to default server type tables relatively recently. application/wasm is required for WebAssembly.instantiateStreaming() to function; if the server returns application/octet-stream instead, the streaming path silently falls back to the slower arraybuffer path in most browsers. font/woff2 must be returned for WOFF2 files; incorrect types may still allow fonts to render but will generate warnings in browser developer tools, signalling a configuration gap worth fixing before it affects security-conscious clients.

Adding these two types to the CI fixture is cheap insurance against a server upgrade that silently drops them from the merged type table, which is exactly the failure that reaches production between major version bumps. A CI check that fails the build on a wrong type turns a quiet regression into a blocking error caught before deploy, drawing its expected values from the deprecated MIME type replacement table. CapyToolkit's MIME reference lists the current IANA-registered types so your expected-value map stays aligned with the standard.

When to use this

Use this guide when auditing legacy server configuration for deprecated MIME types, preparing a server configuration for security assessment, or updating configuration to use modern type registrations.

Examples

types {
    text/javascript  js;
}

types {
    application/javascript  js mjs;
}

types {
    image/x-icon  ico;
}

types {
    image/vnd.microsoft.icon  ico;
}