This page is for the people who want the actual bytes. If you only need to open or convert a file, start with what a JFIF file is instead.
The problem JFIF was invented to solve
ITU-T T.81 — the original 1992 JPEG standard — specifies a compression algorithm and an exchange syntax. It does not specify a file format. It says nothing about which colour space the encoded components represent, nothing about pixel aspect ratio, and nothing about physical resolution.
In practice this meant a JPEG stream was not portable: the encoder and decoder had to already agree on conventions the standard never wrote down. JFIF is that agreement, made explicit and machine-readable. Its normative content is small, which is exactly why it succeeded.
Marker structure
A JPEG file is a sequence of markers. Every marker is two bytes: 0xFF followed by a non-zero identifier byte. A JFIF file begins like this:
FF D8 SOI Start of Image
FF E0 00 10 APP0 segment, length 16 bytes
4A 46 49 46 00 "JFIF\0" identifier
01 02 version 1.02
00 density units (0 = aspect ratio only)
00 01 00 01 X density = 1, Y density = 1
00 00 thumbnail width = 0, height = 0
... DQT, SOF0, DHT, SOS, entropy-coded data
FF D9 EOI End of Image
The FF D8 FF E0 opening is the signature file-identification tools look for. Note that the length field (00 10) counts itself but not the two marker bytes.
The APP0 segment field by field
| Offset | Bytes | Field | Meaning |
|---|---|---|---|
| 0 | 2 | APP0 marker | FF E0 |
| 2 | 2 | Length | 16 + 3 × thumbnail pixels |
| 4 | 5 | Identifier | ASCII "JFIF" plus a null terminator |
| 9 | 1 | Major version | 0x01 |
| 10 | 1 | Minor version | 0x00, 0x01 or 0x02 |
| 11 | 1 | Density units | 0 = no units (aspect ratio), 1 = pixels/inch, 2 = pixels/cm |
| 12 | 2 | X density | Must not be zero |
| 14 | 2 | Y density | Must not be zero |
| 16 | 1 | Thumbnail width | 0 if no thumbnail |
| 17 | 1 | Thumbnail height | 0 if no thumbnail |
| 18 | 3n | Thumbnail data | Uncompressed 24-bit RGB, if present |
All multi-byte integers are big-endian. The embedded thumbnail is stored uncompressed, so it is almost always omitted — a 64×64 thumbnail would add 12 KB of raw RGB to the file.
The colour space rule
JFIF's most consequential clause is the one that is easiest to miss: image data must be encoded as either a single greyscale component or three Y′CBCR components using the ITU-R BT.601 conversion, with full-range (0–255) values.
That is the reason a JPEG produced by a camera in Tokyo displays with correct colour in a browser in Berlin without any negotiation. Raw T.81 offers no such guarantee.
JFIF versus Exif
Exif (JEITA CP-3451, now ITU-T T.872) is the competing convention, and it is what digital cameras and phones actually write. It uses the APP1 marker instead of APP0 and carries a TIFF-structured metadata block: exposure, aperture, ISO, lens, timestamp, GPS coordinates, orientation.
| JFIF | Exif | |
|---|---|---|
| Marker | APP0 (FF E0) | APP1 (FF E1) |
| Standard | ITU-T T.871 | ITU-T T.872 / JEITA CP-3451 |
| Metadata | Density and aspect ratio only | Full camera, GPS and orientation data |
| Thumbnail | Uncompressed RGB, rare | JPEG-compressed, common |
| Typical writer | Browsers, screenshot tools, web encoders | Cameras and phones |
The two are not mutually exclusive — a file may legally contain both segments, and many do. Strictly, Exif requires APP1 to be the first segment after SOI, so files carrying both are technically non-conformant to Exif, but every real-world decoder tolerates it.
This distinction has a practical consequence worth remembering: files saved as .jfif by a browser usually have no Exif block at all, which means no GPS coordinates and no camera identification. Stripping metadata is a privacy improvement, not a defect.
The JFXX extension segment
JFIF defines a second, optional segment identified by the ASCII string JFXX, also carried in APP0. Its only purpose is to allow a thumbnail stored more efficiently — as a JPEG-compressed image or as a palettised one — rather than as raw RGB. It appears rarely in the wild.
How to identify a JFIF file reliably
Do not trust the extension. Read the first four bytes:
FF D8 FF E0with4A 46 49 46 00at offset 6 → JFIFFF D8 FF E1with45 78 69 66 00at offset 6 → ExifFF D8 FF DB→ JPEG with a quantisation table first, no APP header- Anything starting
FF D8 FF→ some JPEG variant
On Linux or macOS, xxd -l 20 image.jfif shows this immediately. On Windows, Format-Hex -Path image.jfif -Count 20 in PowerShell does the same.
Primary sources
- ITU-T Recommendation T.871 (05/2011), Information technology – Digital compression and coding of continuous-tone still images: JPEG File Interchange Format (JFIF) — itu.int
- ITU-T Recommendation T.81 (09/1992), the base JPEG standard — itu.int
- ITU-R BT.601, studio encoding parameters that define the Y′CBCR conversion