JPEG Metadata Explained: Every Segment

JPEG metadata explained: a JPEG is a sequence of self-describing marker segments, and everything that is not picture data lives in one. The file starts with SOI (0xFFD8), then optional APP segments holding EXIF, XMP, IPTC, ICC profiles and comments, then the tables and compressed scan data, and ends with EOI (0xFFD9). Knowing the segment map tells you where a photo’s hidden information sits, and therefore how to remove it.

How a JPEG is framed

Every segment follows the same pattern: the marker 0xFF plus a one-byte identifier, then a two-byte big-endian length, then the payload. The length counts the two length bytes plus the payload, but not the marker.``` FF D8 SOI FF E1 … APP1 (EXIF or XMP) FF DB … DQT FF C0 … SOF0 FF C4 … DHT FF DA … SOS FF D9 EOI

The `APPn` range is `0xFFE0` through `0xFFEF`; `0xFFFE` is the comment marker, `0xFFDB` the quantization table, `0xFFC0`–`0xFFCF` the frame headers, `0xFFC4` the Huffman tables, `0xFFDA` the start of scan and `0xFFD9` the end of image.

## The segment map

| Marker | Segment | Purpose | What it can leak |
| :--- | :--- | :--- | :--- |
| `0xFFD8` | SOI | Start of image; always first | Nothing |
| `0xFFE0` | APP0 | JFIF header, density, legacy thumbnail | A miniature of the photo, sometimes with its own EXIF |
| `0xFFE1` | APP1 | EXIF (`Exif\0\0` + TIFF) **or** XMP (`http://ns.adobe.com/xap/1.0/\0`) | GPS, timestamps, camera, lens, serials, owner name; in XMP, edit history, captions, faces, location |
| `0xFFE2` | APP2 | ICC profile (`ICC_PROFILE\0`), MPF, FPXR | Colour profile; in Apple's case, multi-picture payloads |
| `0xFFED` | APP13 | Photoshop 3.0 IRB (`8BIM` blocks) | IPTC fields, caption, keywords, copyright, a duplicate XMP packet |
| `0xFFEE` | APP14 | Adobe marker: version, flags, colour transform | Colour transform flag, rarely personal data |
| `0xFFFE` | COM | Free-text comment | Software names, scanner notes, operator names, editing history |
| `0xFFDB` | DQT | Quantization tables | Nothing identifying |
| `0xFFC0` | SOF0 | Baseline frame header | Image dimensions and component layout |
| `0xFFC4` | DHT | Huffman tables | Nothing identifying |
| `0xFFDA` | SOS | Start of scan, then entropy-coded pixels | The picture itself |
| `0xFFD9` | EOI | End of image | Nothing |

There is no separate "metadata" object in a JPEG: it is all payload inside these segments.

## Inside APP1: the EXIF block

The EXIF payload in `APP1` (`0xFFE1`) begins with a six-byte identifier, `Exif\0\0` (`45 78 69 66 00 00`), then the TIFF structure. Every offset inside it is relative to the TIFF header, not to the start of the file.

| TIFF header offset | Size | Meaning |
| :--- | :--- | :--- |
| 0 | 2 | Byte order: `II` (`0x4949`) little-endian or `MM` (`0x4D4D`) big-endian |
| 2 | 2 | Magic number, always `0x002A` (42) |
| 4 | 4 | Offset of IFD0 relative to the TIFF header (normally `8`) |

An **IFD** (Image File Directory) is a linked list: a two-byte entry count, then that many 12-byte entries, then a four-byte offset to the next IFD (usually `0`). Each entry is a tag ID (2 bytes), a value type (2 bytes), a count (4 bytes), and either the value itself or a 4-byte offset to it. Type codes include `2` ASCII, `3` SHORT, `4` LONG, `5` RATIONAL (a numerator/denominator pair) and `7` UNDEFINED (opaque bytes). `RATIONAL` is how fractional values are stored: an aperture of ƒ/2.8 is the pair `28/10`, and a 1/500 s exposure is `1/500`.

Four directories hang off IFD0 by pointer:

- **IFD0** — `Make` (`0x010F`), `Model` (`0x0110`), `Orientation` (`0x0112`), `Software` (`0x0131`), `Artist` (`0x013B`), `Copyright` (`0x8298`), plus the pointers `ExifIFD` (`0x8769`), `GPSInfo` (`0x8825`) and `Interop` (`0xA005`).
- **Exif SubIFD** — `ExposureTime` (`0x829A`), `FNumber` (`0x829D`), `ISOSpeedRatings` (`0x8827`), `DateTimeOriginal` (`0x9003`), `FocalLength` (`0x920A`), `BodySerialNumber` (`0xA431`), `LensSerialNumber` (`0xA435`), `MakerNote` (`0x927C`).
- **GPS IFD** — `GPSLatitude` (`0x0002`) and `GPSLongitude` (`0x0004`) as RATIONAL triples in degrees/minutes/seconds, plus `GPSAltitude` (`0x0006`) and `GPSDateStamp` (`0x001D`).
- **Interop IFD** — the compatibility directory, holding `InteropIndex` and flags.

`MakerNote` is special: a single `UNDEFINED` blob whose internal layout is vendor-defined, often starting with a signature such as `OLYMPUS\0`, `Nikon\0`, `FUJIFILM` or `SONY DSC `. Inside it the manufacturer stores duplicate serial numbers, build identifiers, shot counters and sometimes a vendor UUID. That is why a file can report a serial number even when the standard `0xA431` tag is absent.

One subtlety catches people out: IFD0 usually points to a **second IFD (IFD1)** holding the embedded thumbnail — a complete JPEG with its own EXIF block and its own GPS coordinates, so a file can look clean in the main IFD and still leak the location.

## Inside APP1: the XMP packet

XMP occupies an `APP1` segment too, identified by `http://ns.adobe.com/xap/1.0/\0` instead of `Exif\0\0`. The payload is an XML document in W3C RDF form, and it is large: edit history, camera settings, ratings, labels, faces, captions, and a `photoshop:Location` or `exif:GPSLatitude` entry. Above roughly 64 KB, Adobe splits it into a standard part plus an "extended XMP" part in another `APP1` with the identifier `http://ns.adobe.com/xmp/extension/\0`, a GUID, a total length, an offset and a chunk. A tool that only looks for `Exif\0\0` will conclude the file has no metadata, when the XMP is right there.

## The other application segments

`APP13` (`0xFFED`) carries Photoshop's Image Resource Block: the identifier `Photoshop 3.0\0` followed by `8BIM` blocks. The important resource IDs are `0x0404` (IPTC-IIM), `0x0421` (XMP, another copy), `0x0425` (legacy IPTC caption) and `0x042F` (ICC profile). IPTC is where newsroom fields live: byline, credit, caption, headline, keywords, copyright, and the deprecated `Location` field.

`APP2` (`0xFFE2`) carries the ICC profile with the identifier `ICC_PROFILE\0`, a chunk number and a total chunk count. `APP14` (`0xFFEE`) carries the Adobe marker: `Adobe`, a version, two flag bytes and a colour transform value (`0` = unknown/RGB, `1` = YCbCr, `2` = YCCK). `COM` (`0xFFFE`) is a plain comment, a favourite hiding place for notes and old Photoshop strings.

## What a clean JPEG should look like

Ideally, a file you intend to publish contains only:

FF D8 SOI FF E0 “JFIF” APP0 (conventional) FF DB … DQT FF C0 … SOF0 FF C4 … DHT FF DA … SOS FF D9 EOI

No `APP1`, no `APP13`, no `COM`, no `APP2` (unless you want the colour profile), no second IFD with a thumbnail. `exiftool -all= file.jpg` and a good browser-based remover both get you there, with one difference: ExifTool rewrites the container in place, a browser tool has to re-encode the pixels.

## Why the browser re-encodes, and what that costs

There is no browser API for rewriting a JPEG container. The only universally available way to make a new JPEG in a page is to decode the image, draw it onto a `<canvas>`, and call `canvas.toBlob('image/jpeg', quality)`. The browser's encoder writes a fresh file with only the segments it thinks are necessary, which is why every scrap of EXIF, XMP, IPTC and comments disappears.

The trade-offs are real:

- **It is a lossy re-encode.** Your pixels are decompressed and recompressed. At quality 0.92–0.94 the difference is usually invisible, but it is another generation of compression on a file that may already be several generations old.
- **The ICC profile is dropped.** A wide-gamut image (Display P3, Adobe RGB) is reinterpreted as sRGB and can visibly shift colour. The pixel values are unchanged; your screen's interpretation of them changes.
- **EXIF orientation is dropped.** Most modern browsers apply the EXIF orientation when decoding for display, so the pixels usually come out upright — but if the browser does not, the exported file is rotated and the `Orientation` tag that would have fixed it has been deleted. Check [EXIF orientation](/exif-orientation/) first.
- **Large images can fail.** A 12-megapixel image needs roughly 48 MB for one RGBA canvas buffer, and browsers cap canvas dimensions and area.
- **Format changes.** PNG keeps metadata in `tEXt`/`iTXt` chunks and WebP in its own `EXIF`/`XMP`/`ICCP` chunks, so a WebP export is not automatically clean either.

The alternative, which avoids the re-encode entirely, is to rewrite the container: parse the segment list, drop the unwanted `APP`/`COM` segments, and re-emit the file with the untouched `DQT`/`SOF`/`DHT`/`SOS` blocks and the original scan data byte-for-byte. That is why a good browser tool offers both paths: a selective, container-level removal for JPEG that keeps every remaining tag, and a full wipe for when you want a guaranteed-zero file and can accept one re-encode.

## What to do in practice

1. Open the file in the [EXIF viewer](/exif-viewer/) to see which standards are present. The viewer groups tags by source, so you can tell at a glance whether the file carries EXIF, XMP, IPTC or an ICC profile, and whether the GPS IFD is populated.
2. Decide per standard. Removing GPS is usually worth it; keeping the colour profile usually is; the XMP packet is where the editing history lives.
3. Use the [metadata remover](/remove-exif-data/) to strip what you do not want, then rely on its automatic re-scan, which re-parses the exported file and lists every field removed and every field retained. Re-open the exported file in the viewer afterwards: confirm the GPS block is gone, that the maker note is gone if you wanted it gone, and that the thumbnail no longer carries a copy of the metadata.

For the background, see [What is EXIF data](/what-is-exif-data/) and [EXIF vs XMP vs IPTC](/exif-vs-xmp-vs-iptc/). For the practical workflow, start with [remove EXIF data](/remove-exif-data/) and the [GPS photo checker](/gps-photo-checker/).