MIME Types Lookup Online

How to Look Up a MIME Type Online

1. Enter a File Extension or MIME Type: Type a file extension with or without the dot (.json, webp, .heic) to find its Content-Type, or paste a MIME type (application/json, image/avif, video/mp4) to see every extension that maps to it. The search is two-way and case-insensitive.
2. Pick the Right Match: Some extensions map to several MIME types (.xml can be application/xml, text/xml, or vendor-specific like application/atom+xml). The result panel lists the IANA-registered type first, then common non-registered synonyms (image/jpg next to the official image/jpeg).
3. Read the Registration Details (Optional): Each entry shows the registration tree (standards, vendor vnd., personal prs., or unregistered x.), the RFC or specification reference, and any structured-syntax suffix (+json, +xml, +zip). Use this to confirm a type is a real IANA registration before you ship it in production headers.
4. Copy the Content-Type: Click the value to copy Content-Type: application/json; charset=utf-8 ready for nginx, Apache, Express, Django, or whatever stack you're configuring. No sign-up; the lookup runs entirely in your browser.

Why Look Up a MIME Type?

A MIME type (officially a media type per RFC 6838) is the label HTTP, email, and most modern APIs use to tell the receiver what's inside a payload. Pick the wrong one and browsers refuse to render the file, downloads break, file uploaders reject the request, and security headers like X-Content-Type-Options: nosniff start blocking your script tags. Typical reasons to double-check:

• Configuring HTTP servers — nginx's mime.types file, Apache's AddType, and IIS's staticContent all need an exact MIME string. Setting image/jpg instead of the IANA-registered image/jpeg works in most browsers but breaks strict validators and some CDNs.
• Setting accept on file inputs — <input type="file" accept="image/*,application/pdf"> filters the OS picker. Mistyped values silently allow everything through.
• Uploading via REST APIs — multipart/form-data requests need the part's Content-Type to match what the server's parser expects, or you get HTTP 415 Unsupported Media Type.
• Writing service workers and fetch handlers — Response constructors need the correct media type for the browser to treat the bytes as a script, stylesheet, or image rather than application/octet-stream.
• Email and S/MIME attachments — IMAP and SMTP servers honour the MIME Content-Type header to decide whether an attachment is shown inline (image, PDF) or as a download.
• Security hardening — Pairing Content-Type: text/plain with X-Content-Type-Options: nosniff prevents browsers from MIME-sniffing user uploads and executing them as HTML, a common XSS vector.

Working with HTTP payloads at the same time? Use the Base64 encoder when you need to embed a binary file in a JSON body or data URI (which bundles the MIME type and payload together), and the URL encoder for percent-encoding any MIME-type strings you pass as query parameters.

Top 30 Common MIME Types

Sorted by the categories you set most often in web work. The IANA column shows whether the type is in the official media-types registry.

Extension	MIME Type	Category	IANA Registered
.txt	text/plain	Text	Yes
.html / .htm	text/html	Text	Yes
.css	text/css	Text	Yes
.csv	text/csv	Text	Yes
.js / .mjs	text/javascript	Text	Yes (preferred over application/javascript since RFC 9239, 2022)
.json	application/json	Application	Yes (RFC 8259)
.xml	application/xml	Application	Yes (RFC 7303)
.pdf	application/pdf	Application	Yes (RFC 8118)
.zip	application/zip	Application	Yes
.gz	application/gzip	Application	Yes (RFC 6713)
.bin / .exe / unknown	application/octet-stream	Application	Yes (generic binary; triggers download)
.wasm	application/wasm	Application	Yes
.epub	application/epub+zip	Application	Yes
.jpg / .jpeg	image/jpeg	Image	Yes (image/jpg is NOT registered)
.png	image/png	Image	Yes
.gif	image/gif	Image	Yes
.webp	image/webp	Image	Yes (RFC 9649, 2024)
.avif	image/avif	Image	Yes (registered 2021-01-28)
.svg	image/svg+xml	Image	Yes
.ico	image/vnd.microsoft.icon	Image (vendor)	Yes (also commonly image/x-icon)
.mp4 / .m4v	video/mp4	Video	Yes
.webm	video/webm	Video	Yes
.mov	video/quicktime	Video	Yes
.mp3	audio/mpeg	Audio	Yes
.ogg / .oga	audio/ogg	Audio	Yes (RFC 5334)
.aac / .m4a	audio/aac or audio/mp4	Audio	Yes
.wav	audio/wav	Audio	De facto (also audio/wave, audio/x-wav)
.woff	font/woff	Font	Yes (RFC 8081)
.woff2	font/woff2	Font	Yes
.docx	application/vnd.openxmlformats-officedocument.wordprocessingml.document	Application (vendor)	Yes

The vnd. prefix marks the vendor tree (publicly available products like Microsoft Office); structured suffixes like +xml, +json, and +zip tell parsers that the payload uses that underlying syntax even though the top-level type is something else.

MIME Registration Trees — Reading the Subtype Prefix

RFC 6838 splits subtypes into four trees. The first facet of the subtype name tells you which one applies:

Tree	Prefix	Meaning	Example
Standards	no prefix	General Internet use; registered through IETF / standards body review	application/json, image/png, text/html
Vendor	vnd.	Tied to a specific publicly available product, vendor, or organisation	application/vnd.ms-excel, application/vnd.google-earth.kml+xml
Personal / vanity	prs.	Experimental or non-commercial; lighter review	application/prs.alvestrand.titrax-sheet
Unregistered	x.	Private or local use; cannot be registered with IANA	application/x.internal-format

The legacy x- prefix (e.g., application/x-www-form-urlencoded, audio/x-wav) is deprecated by RFC 6648 for new types — names beginning with x- are no longer considered part of the unregistered tree. Existing x- types stay valid for compatibility, but new media types should be registered without it.

Frequently Asked Questions

Where is the official MIME type registry?

The Internet Assigned Numbers Authority (IANA) maintains the canonical list at iana.org/assignments/media-types. It's broken down by top-level type (application, audio, font, image, message, model, multipart, text, video) and shows the registration date, the RFC or specification that defines each type, and the change controller. If a type isn't in that registry, treat it as informal — browsers may still accept it, but strict consumers (CDNs, validators, security scanners) may not.

What does RFC 6838 cover and why does it matter?

RFC 6838 — Media Type Specifications and Registration Procedures defines the rules for naming, structuring, and registering MIME types. It establishes the four registration trees (standards, vendor vnd., personal prs., unregistered x.), describes structured-syntax suffixes like +json and +xml, sets the maximum subtype length at 127 characters, and lays out the IANA submission process. Any media type minted after 2013 should follow these rules — it's the spec your server, browser, and API client all assume is in effect.

Why is application/x-... considered deprecated?

The x- prefix used to mark "experimental, not yet registered." RFC 6648 (June 2012) deprecated this convention for protocol identifiers across the board because the prefix often stuck around long after the type became standard, fragmenting tooling. RFC 6838 then formalised the rule for media types: new ones should be registered in the appropriate tree (standards, vnd., prs., or x. with a period, not a hyphen) and given a proper name. Existing types like application/x-www-form-urlencoded are grandfathered in for backward compatibility, but you should not coin new x- names.

Are image/jpeg and image/jpg the same?

No. Only image/jpeg is registered with IANA, and it covers files whether the extension is .jpg or .jpeg (the extensions differ only because 8.3 DOS filenames couldn't hold four characters). Many browsers and servers silently treat image/jpg as an alias to avoid breaking poorly configured sites, but the W3C, IETF, and HTTP specs only know image/jpeg. Always send image/jpeg in your Content-Type headers and accept attributes.

When should I use the charset parameter on a text type?

For any text/* MIME type, append ; charset=utf-8 (or whatever encoding the file actually uses) to the Content-Type header — e.g., text/html; charset=utf-8, text/csv; charset=utf-8, text/plain; charset=iso-8859-1. Browsers default to a guessed encoding when no charset is declared, which can mangle non-ASCII characters. For binary types (image/*, application/octet-stream, application/pdf), charset is meaningless and should be omitted. application/json is a special case — RFC 8259 fixed JSON to UTF-8, so the charset parameter on application/json is unnecessary (and most servers ignore it).

What is MIME sniffing and why does X-Content-Type-Options: nosniff matter?

MIME sniffing is the browser behaviour of inspecting the first few hundred bytes of a response to guess its real type when the server-declared Content-Type looks wrong. It causes "MIME confusion" attacks: if a site lets users upload .txt files that are secretly HTML, a browser might sniff them as HTML and execute embedded <script> tags, opening an XSS hole. Sending X-Content-Type-Options: nosniff tells the browser to trust the declared Content-Type and refuse to sniff. As a bonus, with nosniff set, scripts must be served with a JavaScript MIME type (text/javascript or application/javascript) and stylesheets with text/css, or the browser blocks them entirely — closing another whole class of vulnerabilities.

Is image/avif an IANA-registered MIME type?

Yes. image/avif was registered with IANA on January 28, 2021, with the Alliance for Open Media as the change controller and the AV1 Image File Format (AVIF) specification as the reference. Browsers shipped support shortly after (Chrome 85, Firefox 93, Safari 16), so it's safe to serve AVIF with the official image/avif MIME type — no need to fall back to application/octet-stream or vendor prefixes. Pair it with a <picture> element and a JPEG/WebP fallback for older browsers.

When should I use application/octet-stream?

Use it as the catch-all for binary data with no more specific registered type — generic firmware blobs, proprietary file formats, or "force download" responses where you want the browser to save the file instead of trying to render it. Pair it with Content-Disposition: attachment; filename="..." to trigger the Save As dialogue. Don't reach for it as a default just because you're lazy — sending a PNG as application/octet-stream will trigger downloads instead of inline rendering, and search engines and social-media unfurlers won't recognise the file. Always use the most specific registered type that fits.

What's the difference between application/xml and text/xml?

Both are IANA-registered (RFC 7303 covers both), but the spec recommends application/xml for almost all uses. The text/xml type predates RFC 7303 and uses US-ASCII as its default charset when no charset parameter is given — which mangles UTF-8 XML. application/xml defaults to UTF-8 per the XML spec. Use application/xml for new code, and only send text/xml when you know an old client specifically needs it. For XML dialects with their own registered type — application/atom+xml, image/svg+xml, application/rss+xml — always use the specific one.