What is JFIF?
JFIF is an interchange convention that places JPEG-compressed image data in a defined file structure. It specifies details such as component alignment, color interpretation, pixel density, and aspect ratio.
How JFIF works
JFIF adds a small, fixed set of conventions to a JPEG stream so that independent decoders interpret it the same way. Its APP0 header segment, required immediately after the start-of-image marker, records a version, a pixel density in dots per inch or per centimeter (or, with units set to 0, only a pixel aspect ratio), and an optional thumbnail. The specification also fixes the color interpretation to grayscale or full-range YCbCr, the sample order to top-down, and the position of subsampled chroma samples relative to luma. The file is still a marker-based JPEG stream, not a box-based container, and other application segments, such as an ICC profile in APP2, may follow the JFIF header. Version 1.02 from 1992 was later formalized as ITU-T T.871 and ISO/IEC 10918-5.
Key facts
- 1Identify JFIF from bytes, not from the suffix: the file starts with SOI (
FF D8), immediately followed by an APP0 segment (FF E0, then a two-byte length) whose data begins with the zero-terminated stringJFIF(4A 46 49 46 00). A JPEG whose first segment is anything else, such as Exif’s APP1, is not a conforming JFIF file even when it is named.jpgor.jfif. Matching this signature shows only that a file declares itself JFIF: conformance also requires a valid JPEG interchange stream and the header and frame constraints in T.871 clause 10.1, such as nonzero density values and one or three components with the identifiers 1, 2, and 3 for Y, Cb, and Cr. - 2JFIF covers only images with one or three channels at 8 bits each: grayscale Y, or YCbCr based on BT.601 and scaled to the full 0–255 range. CMYK and RGB-coded JPEGs fall outside it and are signaled by other conventions such as Adobe’s APP14 marker. The standard itself notes that this gives only basic color fidelity and that an ICC profile may be needed for more accurate color.
- 3JFIF and Exif each require their own segment immediately after SOI (APP0 for JFIF, APP1 for Exif), so one file cannot strictly conform to both. Writers combine them anyway, for example by emitting the JFIF APP0 first and Exif’s APP1 after it; that order satisfies JFIF’s placement rule but not Exif’s. A parser should therefore walk every application segment and check its identifier string instead of assuming one metadata layout.
- 4A JFIF header can embed an uncompressed 24-bit RGB thumbnail, and version 1.02 adds
JFXXextension segments for JPEG-coded, palette-based, or RGB thumbnails. Exif defines its own separate thumbnail mechanism, so a workflow that must find or remove embedded previews has to inspect it as well. These are not the only places a preview can live: Photoshop image resource blocks, for example, can hold another thumbnail.
When JFIF matters
Parsers may encounter JFIF in ordinary .jpg files as well as files named with the .jfif extension. Software must also account for metadata conventions such as Exif that are not fully compatible with JFIF.
Sources
- JPEG File Interchange Format, Version 1.02 (Hamilton, 1992)
- Rec. ITU-T T.871 (05/2011): JPEG File Interchange Format (JFIF)
- Library of Congress: JPEG Encoded File with Exif Metadata, including the JFIF conflict note
- libjpeg-turbo: Using the IJG JPEG Library, “Special color spaces” and “Special markers”
- Adobe Photoshop File Formats Specification, “Image Resource Blocks” and “Thumbnail resource format”