MIME-Version

The HTTP MIME-Version response header declares the MIME protocol version used to construct the message. The value is always 1.0.

Table of Contents

Usage

MIME-Version originates from email, where the header signals a MIME-compliant message body. In email, the header tells mail clients the message uses MIME encoding for attachments, character sets, and multipart structures.

HTTP adopted a different model built around content negotiation through Content-Type and Content-Encoding, with Content-Length handling message framing. These headers handle the same responsibilities MIME-Version serves in email, and HTTP defines no behavior depending on the field.

The header is nonetheless a registered, permanent HTTP field, and sending the value carries a defined meaning: a claim of full MIME conformance for the message, with the sender responsible for the claim holding. The header is harmless in practice, clients ignore the value, and removing the field changes nothing.

Values

1.0

The only value observed in practice. MIME was originally defined in 1992 and revised in 1993 and 1996. No subsequent MIME version has been standardized, so every MIME-Version header contains this same value.

Example

A typical response from a web server including MIME-Version alongside the standard Content-Type header. The 1.0 value indicates MIME version 1.0, the only version defined.

MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8

PDF generation endpoints and document export services frequently include the header because the underlying libraries produce MIME-formatted output. The value remains 1.0.

MIME-Version: 1.0
Content-Type: application/pdf

A conformance claim nobody checks

HTTP permits the header while stating plainly the protocol is not MIME-compliant, and the gap between the two is concrete. MIME requires CRLF line endings in text types where HTTP accepts any line ending. MIME has no equivalent of Content-Encoding, and HTTP makes no use of MIME's transfer encodings. A message carrying MIME-Version asserts conformance across exactly these differences, and servers emitting the field on every response are making a claim no code path verifies.

Only one MIME version was ever standardized, so the field carries no information in practice: the value is 1.0 everywhere or the claim is wrong.

Crawl data shows the header on 136 hosts, always with 1.0. Live checks find major corporate sites among the emitters, and sites behind the same CDN split between sending and omitting the field, which places the origin application rather than the CDN as the source. The email-era roots of the emitting software remain the plausible explanation, and no vendor documents the behavior, so attribution past the origin stays open.

See also

Last updated: August 17, 2026