MIME Type Validator

MIME types: the universal labels of the modern web

A MIME type (Multipurpose Internet Mail Extensions) is a standardized identifier that tells software what kind of content is inside a stream of bytes. Originally designed in 1992 to let email messages carry attachments richer than plain ASCII, the format quickly became the lingua franca of every HTTP server, browser, file uploader and REST API in existence. Without MIME, a browser receiving a stream of bytes would have no reliable way to decide whether to render an HTML page, play an MP3, decode a PNG or download a binary blob.

The original specification spans five RFCs: RFC 2045 (Format of Internet Message Bodies), RFC 2046 (Media Types), RFC 2047 (Header Encodings), RFC 2048 (Registration Procedures) and RFC 2049 (Conformance and Examples). Over the years the model was generalized far beyond email: RFC 6838 (2013) formalizes today's media-type registration rules, and the IANA Media Types registry at iana.org/assignments/media-types serves as the canonical source of truth.

Anatomy of a media type string

Every MIME type follows the shape type/subtype, optionally followed by parameters separated by semicolons. For example: text/html; charset=UTF-8 or multipart/form-data; boundary=----abc123. The top-level type is one of eleven officially registered families:

• text — human-readable text (text/plain, text/html, text/css, text/markdown).
• image — raster and vector images (image/png, image/jpeg, image/svg+xml, image/webp, image/avif).
• audio — sound (audio/mpeg, audio/ogg, audio/wav).
• video — video (video/mp4, video/webm).
• application — generic binary or structured data (application/json, application/pdf, application/octet-stream).
• multipart — composite messages (multipart/form-data, multipart/mixed).
• message, model, font, example, haptics — niche but officially registered.

The subtype can be a registered name (html), a vendor-prefixed identifier (application/vnd.ms-excel, application/vnd.api+json), a personal experiment (application/x-custom) or a structured suffix combining a base format with a serialization, such as +json, +xml, +zip or +cbor — the latter pattern is why image/svg+xml tells parsers "this is SVG, transported as XML".

Real-world uses across HTTP, email and OS

MIME types appear far beyond the obvious HTTP Content-Type response header. They drive the Accept request header used by content negotiation; constrain what HTML file pickers offer through <input type="file" accept="image/*,application/pdf">; label parts inside multipart/form-data uploads; tag attachments inside multipart/mixed emails; and gate service-worker caching strategies. On macOS and iOS, every UTType (Uniform Type Identifier) is mapped to one or more MIME types; on Linux, shared-mime-info drives nautilus, dolphin and freedesktop file association.

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 87

{"ok":true,"user":"alice"}

Modern web platforms add their own subtypes: Web App Manifests ship as application/manifest+json; WebAssembly binaries as application/wasm; Server-Sent Events as text/event-stream; WOFF2 fonts as font/woff2 (the font top-level type was formalized only in 2017 by RFC 8081). Markdown finally landed as text/markdown in RFC 7763 (2016).

Validation: never trust what the client sends

A surprisingly common vulnerability is to trust the MIME type announced by the browser during an upload. The user agent reports whatever the OS guessed from the extension, and attackers can easily rewrite the value with a proxy. Robust pipelines therefore validate uploads in two layers: (1) syntactic check that the string matches a known registered media type, and (2) magic-byte sniffing against the first few bytes of the actual file — PNG always starts with 89 50 4E 47, PDF with %PDF-, JPEG with FF D8 FF. Mature libraries such as mime-types (npm), python-magic (libmagic bindings) and Apache Tika handle both layers.

Browsers also perform content sniffing when servers send a missing or generic Content-Type. While convenient, this behaviour has caused real XSS incidents (a file uploaded as text/plain being executed as HTML). The countermeasure is the response header X-Content-Type-Options: nosniff, which forbids the browser from second-guessing the declared type.

Common pitfalls and anti-patterns

• Forgetting charset=UTF-8 on text/html and text/plain — leads to Mojibake when the page contains accented characters.
• Using application/octet-stream as a fallback for unknown payloads is acceptable but disables in-browser preview.
• Returning text/html for a JSON API endpoint — confuses clients and breaks CORS preflight in some setups.
• Confusing application/x-www-form-urlencoded with multipart/form-data — only the second can carry file uploads.
• Inventing custom types like text/json instead of the registered application/json.

FAQ

Should I validate uploads only by MIME type? No. The MIME type announced by the client is trivially spoofable. Always verify the magic bytes of the actual stream server-side and ideally re-encode images through a hardened library.

What is the right MIME type for a multipart file upload? multipart/form-data; boundary=.... The boundary parameter is mandatory and must be unique within the message; libraries generate it automatically.

How do I register a brand-new MIME type? Submit a request to IANA following RFC 6838. Personal or experimental types should use the x. prefix; vendor types go under vnd..

Are types case-sensitive? No. Application/JSON and application/json are equivalent per RFC 2045, but the lowercase form is the canonical convention.

Why does my browser ignore the type I sent? Either you forgot X-Content-Type-Options: nosniff and the browser sniffed the content, or there is an upstream proxy rewriting the header. Inspect the response in DevTools to confirm.