MIME Types Reference

MIME types (Multipurpose Internet Mail Extensions) are an internet standard for indicating the nature and format of documents, files, or byte streams. Browsers and servers use MIME types to determine how to handle received content. For example, when a browser receives image/jpeg, it displays an image; application/pdf might open a PDF preview. Setting correct MIME types is crucial for web applications to function properly. MIME types describe what kind of content a file or HTTP response contains, such as text/html, application/json, image/png, or application/pdf. They affect browser rendering, downloads, API parsing, upload validation, caching, and security behavior. File extension and MIME type do not always match, so checking them matters when diagnosing server configuration, unknown files, or upload problems. For security, MIME types should not be trusted blindly; content inspection, extension rules, and an explicit allowlist should be used together.

MIME types (Multipurpose Internet Mail Extensions) are standardized identifiers for data formats, originally defined in RFC 2045/RFC 2046 for email attachments and later adopted by HTTP (RFC 7231 §3.1.1.5) for web content negotiation. A MIME type is structured as type/subtype — the type declares the broad category (text, image, audio, video, application, multipart, font, model) and the subtype specifies the exact format (e.g., text/html, image/png, application/json). Optional parameters follow a semicolon (text/html; charset=utf-8). The Internet Assigned Numbers Authority (IANA) maintains the official MIME type registry at iana.org/assignments/media-types. Registration follows RFC 6838, which defines a review process requiring a specification document, security considerations, and interoperability notes. Unregistered types can use the x- prefix (e.g., application/x-tar) as a convention for experimental or vendor-specific formats, though RFC 6648 recommends avoiding the x- prefix in favor of proper registration. In HTTP, the Content-Type header tells the client how to interpret the response body. A server returning Content-Type: image/svg+xml triggers the browser's SVG renderer; Content-Type: application/octet-stream triggers a download prompt because the browser cannot determine the format. The browser also uses MIME type information for MIME sniffing — when a server omits Content-Type or sends a generic type, the browser may inspect the first few bytes of the response (magic bytes) to guess the actual format. This behavior is controlled by the X-Content-Type-Options: nosniff header, which disables sniffing and requires the server to declare the correct type. For file uploads, the Accept header tells the server what MIME types the client expects in response, while the input element's accept attribute restricts the file picker to specific types (e.g., accept="image/png, image/jpeg"). On the server side, uploaded files should be validated by both their declared MIME type and their file signature (magic bytes), as neither alone is trustworthy — a file named image.png with Content-Type: image/png could contain executable code. The tool serves as a reference for looking up the canonical MIME type for a given file extension, covering 100+ common formats across eight categories.

• RFC 2046 structure: type/subtype — the type indicates the broad content category and the subtype the exact format; optional parameters follow a semicolon (text/html; charset=utf-8) and are case-insensitive by spec, though lowercase is the convention.
• IANA registration (RFC 6838): New media types require a specification document, security considerations section, and interoperability notes — the review process ensures types are well-documented and conflicts are avoided before they enter the registry.
• HTTP Content-Type header: The server declares the MIME type of the response body; browsers use it to select the appropriate renderer (HTML parser, image decoder, PDF viewer) or trigger a download — an incorrect Content-Type is the most common cause of 'file downloads instead of displaying' bugs.
• MIME sniffing and X-Content-Type-Options: When Content-Type is missing or generic, browsers may inspect magic bytes to guess the format — X-Content-Type-Options: nosniff disables this behavior and requires an exact Content-Type match, which is a security best practice.
• application/octet-stream: The generic binary fallback type — browsers treat it as an opaque stream and trigger a download, making it the safest default when the server cannot determine the format, but it prevents in-browser preview of otherwise displayable content.
• File upload validation: The input accept attribute filters the file picker client-side, but server-side validation must check both the declared Content-Type and the file's magic bytes — a mismatch between extension, MIME type, and file signature is a red flag for malicious uploads.
• Vendor-specific and experimental types: The x- prefix convention (application/x-tar, video/x-matroska) predates the formal registration process — RFC 6648 recommends migrating these to proper IANA-registered types where possible, but many remain in widespread use.