Does a Screenshot Capture Your Color Profile?

How we tested it (real bytes, not a guess)

We did not repeat a blog post. Four sources of first-hand data, all read on 2026-10-30 with Pillow 12.3.0 on Python 3.13, except where noted.

1. A live browser capture. Chrome 156 headless rendered https://watermarkstrip.com at 1280×800 and wrote a PNG of 44,617 bytes. Its chunk list was IHDR, IDAT ×12, IEND. No iCCP, no sRGB, no gAMA, no cHRM. PIL.Image.info was empty.

2. Every PNG this site serves. We walked all 28 PNG files in the site's img/ tree and root. All 28 contained exactly IHDR, one or more IDAT, IEND. Zero files carried any color chunk.

3. Real Windows screenshots. On 2026-09-15 we had byte-read four Snip & Sketch PNGs on this same machine. All four returned the same chunk list: IHDR, sRGB, gAMA, pHYs, IDAT, IEND. That is the one capture path we have seen write a color tag at all.

4. A controlled build. We made one 800×600 RGB image and saved it six ways, then injected the remaining chunks by hand with correct CRCs. Every size and byte count below comes from that run, not from documentation.

What “color profile” actually means inside a PNG

PNG has no single color field. It has four optional chunks, and they are not interchangeable:

• iCCP — a real ICC profile, zlib-compressed, preceded by a profile name and a compression-method byte. This is the only chunk that can describe a specific device or working space.
• sRGB — exactly 1 byte: the rendering intent (0 = perceptual, 1 = relative colorimetric, 2 = saturation, 3 = absolute colorimetric). It says “treat these pixels as sRGB,” nothing more.
• gAMA — 4 bytes: gamma × 100,000. The sRGB value is 45,455, i.e. 1/2.2.
• cHRM — 32 bytes: eight 4-byte chromaticity values × 100,000, for white point and the R/G/B primaries.

The PNG specification gives them an order of precedence: if iCCP is present it wins; otherwise sRGB; otherwise gAMA plus cHRM. If none of the four is present, the decoder is told to assume sRGB. That last rule is why a screenshot with no color chunk still looks right in your browser — nothing was lost, because nothing was ever written.

A screenshot never carries your monitor's ICC profile

The capture path makes this structural, not incidental. A screenshot is taken from the composited frame buffer, which the OS has already converted into the display's color space for presentation. The encoder receives finished pixels. It has no handle on the ICC profile you assigned to that monitor in Windows Color Management, so it has nothing to write into iCCP.

Our test confirms it: an iCCP chunk only appeared when we explicitly handed Pillow an icc_profile argument. That produced a 373-byte iCCP payload named ICC Profile with compression method 0, and the file grew from 2,806 to 3,191 bytes (+385). We did not ask for it, so it was not there. Neither Chrome, nor Pillow, nor Snip & Sketch asked for it either.

The practical consequence: if you calibrated your monitor with a colorimeter and the vendor's profile, that calibration does not travel with your screenshots. Anyone opening the file sees the pixels you saw, interpreted as sRGB — which is close, but not identical, to what a wide-gamut display showed you.

The one thing screenshots do write: an sRGB tag

Windows Snip & Sketch writes sRGB and gAMA on every capture. We measured the pair on our injected test file: sRGB with intent 0, and gAMA at 45,455, which Pillow reads back as gamma: 0.45455. Together they cost 13 and 16 bytes of chunk overhead.

Chrome's Page.captureScreenshot writes neither. Pillow's default save writes neither. So the presence of an sRGB tag is a property of the capture tool, not of screenshots in general — and definitely not of your hardware. That makes it a weak software fingerprint: enough to guess which tool produced a file, not enough to identify a machine.

For the same reason, an sRGB tag is not evidence that the screenshot is “color-accurate.” It is a promise about interpretation, and it is a promise every conforming decoder already makes when the chunk is absent. See does a PNG have EXIF data for why the PNG container keeps metadata this thin in the first place.

Same pixels, different tags — the exact byte cost

We started from one 800×600 image and changed only the color chunks. Every variant decoded to byte-identical pixel data.

• No color chunk — 2,806 bytes. Chunks: IHDR, IDAT, IEND.
• sRGB injected — 2,819 bytes (+13). sRGB len=1, intent=0. Pillow reads info['srgb'] = 0.
• gAMA injected — 2,822 bytes (+16). gAMA = 45,455 → 0.45455.
• cHRM injected — 2,850 bytes (+44). cHRM len=32 → white (0.3127, 0.3290), R (0.64, 0.33), G (0.30, 0.60), B (0.15, 0.06).
• All three — 2,879 bytes (+73). Pillow reports srgb, gamma and chromaticity together.
• Full ICC profile — 3,191 bytes (+385). iCCP len=373, name ICC Profile, compression 0.
• DPI only — 2,827 bytes (+21). pHYs = 4724×4724, unit 1.

Pixel comparison against the untagged original returned true for all six variants. This is the whole point: color chunks describe how to interpret pixels, they never change the pixels. Removing one costs you nothing visually unless a viewer was relying on it to correct a non-sRGB image.

In JPEG the profile goes to APP2, not to EXIF

The same test image saved as JPEG with the same ICC profile put the profile somewhere else entirely. The file was 8,872 bytes, the ICC_PROFILE identifier sat at byte offset 24, and the APP2 segment length was 604 bytes. There was no Exif\x00\x00 marker anywhere in the file.

This matters because “strip the EXIF” and “strip the color profile” are two different operations on a JPEG. A tool that clears APP1 removes camera, GPS and timestamp fields and leaves the ICC profile intact. A tool that clears APP2 removes the profile and leaves your GPS coordinates alone. If you are removing metadata for privacy, check which segments actually went away — see do screenshots have timestamps for the analogous trap in the time field.

Does the color chunk tell anyone anything about you?

Not about your device, and not about your location. An sRGB chunk is a constant: the same byte in every file that has one. gAMA at 45,455 is likewise constant. cHRM with the sRGB primaries is constant. None of them is derived from your panel, your serial number, or your calibration.

An iCCP chunk is different in kind, because it can contain a named profile with a vendor and model string inside. But screenshots do not produce one unless the capturing software was explicitly told to embed a profile, and none of the capture paths we tested does that.

So the honest ranking of what a color chunk reveals is: iCCP > sRGB+gAMA > nothing, where the middle case tells a careful reader which tool you used and the last case tells them nothing. Compare that with the metadata that does identify a machine — see do screenshots contain device info, where we byte-grepped a username and a PC name out of a real capture.

How to check your own screenshot in ten lines

You do not need a metadata viewer to answer this. A PNG chunk walk is a dozen lines, and it works on any file:

import struct
data = open('shot.png','rb').read()
assert data[:8] == b'\x89PNG\r\n\x1a\n'
i = 8
while i < len(data):
    ln = struct.unpack('>I', data[i:i+4])[0]
    print(data[i+4:i+8].decode('latin1'), ln)
    i += 12 + ln

If the output contains iCCP, the file embeds a full profile. If it contains sRGB and gAMA but no iCCP, it carries only a label. If it prints IHDR, IDAT, IEND and nothing else, there is no color metadata at all and your viewer is assuming sRGB.

To remove an embedded profile, re-save the image without passing icc_profile; Pillow drops the chunk and the pixels stay identical. To confirm nothing else rode along, check the chunk list again — pHYs survives that round trip, which is why a stripped screenshot still reports 119.99 DPI.

FAQ

Does a screenshot capture my monitor's color profile? No. The capture reads the already-composited frame buffer, so the encoder never sees the ICC profile you assigned to the display. We confirmed this on a live Chrome capture and 28 site PNGs: no iCCP chunk in any of them.

Why does my screenshot have an sRGB chunk then? Because Windows Snip & Sketch writes one. It is a 1-byte rendering-intent tag plus a gAMA of 0.45455, not a profile. Chrome's screenshot API and Pillow's default save write neither chunk.

Is an sRGB chunk the same as an ICC profile? No. sRGB is one byte declaring a known color space. iCCP is a compressed profile that can describe a specific device. In our test the sRGB tag cost 13 bytes and the ICC profile cost 385.

Does the color chunk change how my screenshot looks? Not in a browser. All six variants we built had byte-identical pixels. The chunk changes how a decoder interprets pixels that were encoded in a different space; sRGB pixels plus an sRGB tag are a no-op.

Can a screenshot reveal my monitor model? Not through color metadata. The chunks that screenshots do write are constants shared by every file from the same tool. Device identity, when it leaks, comes from fields like the username and PC name we found in a real capture.

Does removing the color profile shrink the file? Yes, by exactly the chunk size: 385 bytes for the 588-byte sRGB profile we embedded, 13 bytes for an sRGB tag, 16 for gAMA, 44 for cHRM. On a 44 KB screenshot that is under 1%.

What if a PNG has no color chunk at all? The PNG specification tells decoders to assume sRGB. That is the normal state of a Chrome screenshot, and it is why the file still renders correctly everywhere.

Related reading

If you are tracing what a screenshot keeps and drops, these are the next reads:

• do screenshots have exif data — the main guide: every field a screenshot carries, and every field it loses.
• Why your screenshot says 119.99 DPI — the other metadata chunk that survives stripping, measured the same way.
• What metadata do screenshots have? — the full chunk inventory, enumerated on real files.
• Do screenshots contain device info? — where a username and PC name actually hide in a capture.