A MIME Type Lookup API alternative is a tool that resolves registered media types without calling a third-party service, sending bytes over the network, or depending on an installed system library. The MIME Type Lookup reference works entirely inside the browser tab: type an extension like .json, a family like image, a full registered value like font/woff2, or a plain-English format description, and the table filters a curated set of 24 IANA-registered media types in memory. Each row keeps the description, the extension aliases, and the exact base type together so a single registered string — image/png, application/json, text/javascript — can be copied directly into a Content-Type header, an upload allowlist, a test fixture, or a configuration file. Because no file is opened, no upload happens, and no request leaves the page, the lookup avoids rate limits, network latency, vendor lock-in, and the privacy concerns that come from shipping filenames or partial bytes to a remote endpoint.
The Case for a Browser-Local MIME Type Reference
External MIME type lookup endpoints introduce dependencies that are easy to forget: a network round-trip on every guess, rate limits during load tests, vendor outage risk inside CI, and the privacy question of which filenames or byte prefixes are sent off-device. A browser-local reference avoids those concerns because the mapping table ships with the page and filters in memory. The reference delivers 24 curated IANA media types that cover most web responses, document uploads, image pipelines, audio and video elements, archive downloads, font loading, and binary fallbacks. The same pattern applies to other developer references that want to live next to the developer instead of behind a paid SaaS, and the broader approach to "validate locally instead of calling an endpoint" is described in file signatures list API alternatives for magic-byte lookup.
Operating entirely client-side also makes the lookup reproducible: the same query in the same browser always returns the same row, so test fixtures stay stable and onboarding a new teammate does not require provisioning an API key. A local reference fits cleanly into offline documentation, internal style guides, and air-gapped environments where reaching an external service is not an option.
How the Reference Is Built and What It Covers
The table stores 24 IANA-registered media types with a unique identifier and a unique base type string. Search filters the normalized extension, the media type, and the description fields together, so a single query resolves three different entry points: .json, the family name image, or the full registered value font/woff2. Eight external fixtures lock the mappings for HTML, CSS, JavaScript, JSON, PNG, JPEG, SVG, and WOFF2 so the most common anchors stay stable across updates. The generic fallback application/octet-stream is intentionally included without an extension attached, because unknown binary data has no single honest filename.
Copying a row copies only the media type — never the row ID, the description, or the alias list — so the clipboard always holds a value that pastes directly into a response header or an upload allowlist. The IANA Media Types registry and the MDN common media types table both inform the curated set, and the reference links back to those authorities whenever a format lies outside the 24-row scope. Everything on the page runs locally: search text is filtered in memory, copying uses the browser clipboard after a click, and no file is opened or uploaded.
Look Up a Media Type in Three Steps
- Enter an extension, format name, or media type in the search field. Typing png, image, or image/png all surface the same row because the filter looks across the normalized extension, the top-level family, and the base type. A query for json returns application/json; a query for woff2 returns font/woff2; a query for javascript returns text/javascript even if the value is remembered as text/jscript or application/x-javascript.
- Confirm the matching description and extension aliases. The description is plain English ("JPEG image") and the aliases list every filename extension the format commonly uses (.jpg, .jpeg, .jfif when present). Treat the base type as authoritative and the aliases as practical hints that match filenames, not bytes.
- Copy the exact base media type and validate it against the real content before use. Paste image/png into a response header, a CDN rule, an upload allowlist, or a test fixture, then confirm the header on the deployed response and the bytes on the stored object before treating either as trustworthy.
Where Extensions, Headers, and Sniffed Types Disagree
Extensions are hints, not proof, and a browser-supplied File.type value can be empty, stale, or derived from the operating system's extension map rather than the bytes themselves. A file named picture.png can carry non-PNG content; an attacker can rename evil.bin to evil.png without changing what is inside. Same-origin requests, embedded resources, and downloads all rely on the server-sent Content-Type to apply protections such as nosniff and to choose the correct decoder. A wrong value prevents modules, stylesheets, fonts, media, or downloads from loading, and on the upload side it lets an allowlist built only on extension admit payloads it should have rejected.
Secure upload handling therefore inspects the actual content, enforces strict size and format limits, decodes with a safe maintained parser, renames stored objects, isolates them from execution, and applies authorization — and a lookup table, a request header, or a sniffed type is never the only security decision. Parameters such as charset=utf-8 are not a harmless universal default either; they belong with text-based formats and only when the registered base type actually accepts them. The reference intentionally lists only the base registered type, so charset declarations, boundary parameters, codecs, content disposition, compression, and transfer encoding remain separate decisions a developer makes after the base type is fixed.
Common Media Types Anchored by the Reference
The table below lists the eight fixture-locked mappings plus the generic binary fallback. Every value comes straight from the curated set and from the IANA and MDN sources behind it; treat these as the current common mapping rather than a guarantee that every server, registry, or historical browser agrees.
| Description | Base media type | Common extensions |
|---|---|---|
| HTML document | text/html | .html, .htm |
| CSS stylesheet | text/css | .css |
| JavaScript module | text/javascript | .js, .mjs |
| JSON data | application/json | .json |
| PNG image | image/png | .png |
| JPEG image | image/jpeg | .jpg, .jpeg |
| SVG vector image | image/svg+xml | .svg |
| WOFF2 font | font/woff2 | .woff2 |
| Generic binary data | application/octet-stream | (none) |
Some formats carry contextual or historical alternatives. XML can be served as application/xml, while specialized XML vocabularies use dedicated +xml subtypes such as image/svg+xml or application/atom+xml. JavaScript historically appeared under several legacy values (text/jscript, application/x-javascript, application/javascript); current web guidance and IANA registration use text/javascript. A .gz archive may be labeled with the registered application/gzip or a platform's nonstandard x-gzip value, and the reference keeps one current common mapping rather than pretending every platform agrees.
Limits of the Curated Set and the IANA Source of Truth
The reference is deliberately bounded at 24 rows rather than mirroring the full IANA registry, which contains thousands of registered subtypes across dozens of top-level trees. Vendor-specific office formats, multipart boundary construction, email transfer encodings, codec parameters, and obscure registered subtypes all sit outside the curated set, and the tool points back to the IANA registry when a format is missing or when a protocol contract depends on the newest registration. Registrations and implementation guidance can evolve independently of any curated set, so recheck the primary registry before shipping a strict uploader or a documented Content-Type policy.
Treat unknown content as untrusted binary data, prefer an explicit allowlist over accepting every row in the table, and remember that a correct Content-Type helps browsers interpret responses and enables protections such as nosniff to work as intended. The reliable workflow stays the same: locate the desired format in the table, confirm the bytes actually match it, copy the registered base type, and test the real response or upload path on the deployed system.
For a deeper look, see PX to REM Without an API: A Local Browser Workflow.