mime-db

mime-db is the canonical MIME type database used across the Node.js ecosystem, providing a plain JSON object that maps thousands of media types to their known file extensions, default charset, and whether the type is typically compressible. Rather than hand-maintaining these mappings, the package aggregates data from three authoritative upstream sources — the IANA media type registry, the Apache httpd project, and nginx — merging them into one deterministic, sorted db.json file that ships as the package’s only meaningful export.

Because it has zero runtime dependencies and no logic beyond a single require('./db.json'), mime-db is easy to vendor into other libraries (such as mime-types and send) that need MIME resolution without taking on their own maintenance burden for tracking new or changed media types. Updates land as small, auditable diffs to the generated JSON whenever an upstream registry adds or changes a type.

What You Get

• A single db.json file mapping 2,600+ MIME types to extensions, charset, and compressibility flags
• Deterministic build output — types and their properties are alphabetically sorted for stable, reviewable diffs
• Aggregated data from IANA, Apache httpd, and nginx registries kept in sync via automated fetch scripts
• A zero-dependency runtime footprint — the published package is just the JSON data plus a one-line index.js

Common Use Cases

• Resolving the correct file extension for a given MIME type when serving or naming downloaded files
• Determining whether a response body should be gzip-compressed based on its content type
• Looking up the default charset for a content type before setting response headers
• Powering higher-level libraries like mime-types and send that need MIME/extension mapping without maintaining their own registry

Under The Hood

Architecture The package separates build-time generation from runtime consumption: scripts/build.js reads src/iana-types.json, src/apache-types.json, and src/nginx-types.json, layers in src/custom-types.json and src/custom-suffix.json for manually curated entries, and writes the merged result through scripts/lib/write-db.js, which sorts keys and writes deterministic, diff-friendly output to db.json. At runtime, index.js does nothing more than module.exports = require('./db.json'), so the entire published surface area is a static data structure with no logic to break.

Tech Stack The project is plain JavaScript with no runtime dependencies at all. Development tooling covers the full lifecycle: csv-parse and undici power the scripts/fetch-* scripts that pull fresh data from the Apache and nginx upstreams, eslint with the standard config enforces style, and mocha plus nyc run and measure coverage of the test suite. media-typer is used only inside the tests to validate that every generated key is a syntactically valid MIME type.

Code Quality The test suite in test/index.js doesn’t test business logic so much as it enforces invariants on the generated data: every type must trace back to a src/*-types.json source, must be lowercase, must be a valid MIME type per media-typer, and extensions must be lowercase with the preferred extension listed first. CI (.github/workflows/ci.yml) runs lint, then rebuilds db.json from source and fails the build if the committed file has drifted from a fresh build, which is the project’s real safeguard against hand-edited or stale data reaching npm.

API Design The public API is as minimal as it gets — a single require('mime-db') call returns a plain object keyed by lowercased MIME type, with .source, .extensions, .compressible, and .charset documented per entry in src/README.md. There is no configuration, no methods to learn, and no async behavior, which is precisely why so many other packages in the ecosystem (mime-types, send, express) depend on it directly as their data layer rather than reimplementing MIME lookups themselves.