← Blog

ICC profile — the metadata you should not strip

ICC profile lives in APP2 (JPEG) or iCCP (PNG) — describes how to interpret pixel values JPEG container FF E2 + "ICC_PROFILE\0" + sequence + total + profile bytes profile may span multiple APP2 chunks (≤ 64 KB each) PNG container iCCP chunk: profile-name + null + compression-method + zlib(profile) Common profile names you'll see in our viewer "sRGB IEC61966-2.1" 2096 bytes — the web default "Display P3" 548 bytes — iPhone 7+, modern Macs "Adobe RGB (1998)" 560 bytes — pro photo workflow "ProPhoto RGB" ~3 KB — widest gamut, RAW workflows

Most metadata in a photo is informational — interesting if you care about who shot it, irrelevant if you just want to display the pixels. The ICC profile is the exception. It changes how the pixels are rendered. Strip it and the same RGB values that produced a deep red on the camera's wide-gamut display become a duller, flatter red on whatever device opens the file next.

What an ICC profile describes

An ICC profile is a binary document specified by the International Color Consortium. Inside is a description of how to convert the file's RGB pixel values into a device-independent colour space (CIE XYZ or LAB) and back to whatever device will display them. Two parts matter most: the gamut (which colours the source can produce — wider on Display P3 than sRGB, wider still on Adobe RGB) and the tone curves (how brightness values map to physical light intensity).

A profile-aware viewer reads the embedded profile, computes the conversion to the display's profile, and renders accurate colour. A profile-unaware viewer skips this step and treats the RGB values as if they were sRGB — which works fine for sRGB sources and produces washed-out or oversaturated results for everything else.

Where it lives in JPEG

APP2 marker, hex 0xFFE2. Payload starts with the literal twelve-byte string "ICC_PROFILE\0", followed by a one-byte sequence number, a one-byte total-chunk count, and the profile bytes. Profiles larger than the 64 KB JPEG marker limit are split across multiple APP2 chunks; readers concatenate them by sequence number.

Display P3 profiles from iPhones are typically 548 bytes — they fit in one chunk. Calibrated monitor profiles can be 5 KB or more and span two or three chunks.

Where it lives in PNG

The iCCP chunk, defined in PNG 1.1 (1998). Payload: a profile name as a Latin-1 string, a null terminator, a one-byte compression method (always zero — zlib), and the deflated profile bytes. The profile name is informational; readers ignore it and parse the actual ICC bytes that follow.

Why stripping degrades the photo

The pixel values in an iPhone photo are encoded in Display P3 — a wide-gamut colour space with deeper reds and greens than sRGB. The ICC profile tells viewers "these RGB values are P3, convert them appropriately for your display". Without the profile, a viewer assumes sRGB and renders the same RGB values as if they were sRGB — which means the deep saturated reds get clipped and the overall image looks slightly desaturated and yellowish.

This is why every modern photo-management workflow preserves ICC profiles end to end and why our generic metadata-strip tool keeps them by default. Stripping ICC saves a few hundred bytes and breaks the colour pipeline.

Three profiles you'll see most

How our viewer shows it

The WASM-bundled metadata reader extracts the ICC payload from APP2 (or iCCP for PNG), parses its header, and surfaces the profile name and size. The profile description (a short human-readable name like "Display P3") is shown alongside the technical name (the full desc tag content). If you're auditing what's in your file before publishing, the ICC line is the one to leave alone.