Do Screenshots Have Copyright Metadata? What We Embedded, What We Captured

Q: If my copyright watermark is still visible after a screenshot, did the copyright survive?

Only as pixels, not as metadata. A visible © drawn into the image is content, and content rides along in a screenshot. It survives, but anyone can crop or paint over it, and the machine no longer asserts ownership. That is a different thing from copyright metadata.

No — a screenshot carries no copyright metadata, but it can carry a visible copyright notice, and the two are not the same thing. We built a 1200×800 photo on this machine carrying an EXIF Copyright tag (© 2026 Jane Doe), an XMP rights packet (dc:rights), and a © watermark drawn into the pixels. We then turned the pixels into a PNG the way every OS snipping tool does. The PNG came back with 0 EXIF fields, no eXIf chunk, no XMP, and no text chunk holding a copyright — every embedded claim of ownership was gone. But the © we drew on the image survived, because it is pixels, not metadata. For the baseline on what a screenshot actually carries, start at do screenshots have exif data.

What we measured, and how (read this first)

Being precise here matters, because the honest answer is a split decision and the split is the whole point. We measured two things directly with Pillow 12.3.0 and piexif 1.1.3 on Python 3.13, on 2026-11-10: (1) the copyright metadata inside a source photo, and (2) whether any of it survived after the photo’s pixels became a PNG. We did not literally press a snip key on this headless machine — instead we modelled the screenshot at the pixel level, because a screenshot is exactly a PNG of the on-screen pixels, which is the same operation every OS snipping tool performs. Our earlier measured run on this machine (do screenshots have exif data) confirmed that four real Windows Snip & Sketch captures produced PNGs with zero eXIf chunks — we label that one as previously measured, not re-run today. Everything below about what a screenshot is leans on that, and everything about the copyright container is from this machine’s test.

The source photo: EXIF Copyright + XMP rights + a visible notice

We created a 1200×800 JPEG and deliberately wrote three kinds of copyright claim into it, so there was something real to lose.

EXIF Copyright tag (0x8298): value © 2026 Jane Doe, plus an EXIF Artist tag Jane Doe. Read back through piexif, the file held 7 EXIF fields in total, and the Copyright tag was present and returned the exact string we wrote.
XMP rights packet: an Adobe XMP APP1 segment carrying <dc:rights>Copyright 2026 Jane Doe, all rights reserved</dc:rights> and a dc:creator of Jane Doe. A raw-byte search of the file found the word rights and the full statement, so the packet was genuinely embedded.
A visible copyright notice: we drew © 2026 Jane Doe as black text into the image pixels, in the bottom-left, the way a person watermarks a screenshot by hand.

The file was 30,367 bytes, MD5 34af8b1f2f1247a355c5c0509a84a52f. Every number in this paragraph came from that run.

What a screenshot actually is

A screenshot is a raster capture of whatever is drawn on the screen, and every OS snipping tool writes it out as a PNG — Windows Snip & Sketch, macOS Screenshot, and Android/iPhone capture all produce PNG. PNG has no EXIF segment at all; there is literally no container for it. Our earlier measured run confirmed the practical consequence: four real Windows Snip & Sketch PNGs contained the chunks IHDR, sRGB, gAMA, pHYs, IDAT and IEND, and zero eXIf chunks and zero EXIF fields. So a screenshot starts from a format that cannot hold EXIF, and the same is true for the XMP and IPTC containers — they live in JPEG/TIFF segments that a PNG simply does not have.

The screenshot test: copyright metadata before and after

This is the core measurement and it answers the question. We opened the 7-field, copyright-tagged, XMP-bearing source photo and saved it as a PNG — the exact transformation a snip performs on the displayed pixels. The result, byte by byte:

Size 23,112 bytes, MD5 22f1e9e5f167224008ec4a31db0f25e0.
EXIF fields: 0. piexif could not parse any EXIF out of the PNG at all; the Copyright tag and the Artist tag were both gone.
No eXIf chunk. A chunk walk of the PNG returned only IHDR, IDAT, IEND — no eXIf, and no tEXt, iTXt or zTXt text chunk of any kind.
No XMP. The raw bytes no longer contained the word rights or the dc:rights statement; the XMP packet was gone.

So every embedded claim of ownership — the EXIF Copyright tag, the XMP rights packet — dropped to zero. A screenshot does not carry copyright metadata.

The one thing that survives: a visible copyright notice

The © 2026 Jane Doe we drew into the pixels did survive, and that is the trap. We scanned the bottom strip of the screenshot PNG for dark pixels where the notice was drawn, and found them — the visible text is intact, because a screenshot copies pixels and the watermark is part of the pixels. This is why people get confused: they see their © still on the picture and assume the “copyright” survived. It did not survive as metadata. It survived as content, the same way any other part of the image survives. Anyone can crop it out or paint over it; the machine no longer asserts that you made it.

Three containers, three different fates

“Copyright metadata” is not one thing. There are three containers people mean, and a screenshot treats all of them the same way — it drops all of them — because none of them live in the pixel buffer:

EXIF Copyright (0x8298) and Artist (0x013B) — live in the JPEG/TIFF APP1 EXIF segment. We measured them present in the source and absent in the PNG.
XMP rights / dc:rights — lives in its own APP1 packet. We measured it present in the source and absent in the PNG.
IPTC copyright (2:116 / 2:80) — lives in the APP13 segment. We did not write IPTC into this test file, so we label its behaviour as not-measured-here rather than claim a result; the principle is identical — it is a file-level segment, not a pixel, so a screenshot does not carry it.

The useful takeaway: a screenshot is blind to which container you used. It removes all of them by removing the concept of file metadata entirely.

Why metadata drops but visible content stays

The distinction is the pixel-versus-file boundary. Metadata lives in the file’s sidecar segments; it is never part of the rendered image. A screenshot only ever copies the rendered image, so the metadata is simply never in scope. Visible content — a watermark, a signature, a license plate in a photo — is already pixels, so it rides along for free. This is the same reason a screenshot removes GPS, camera serial numbers and edit history: they are all in the metadata layer, and the screenshot never sees that layer. We cover the GPS half of this in do screenshots have exif data, which is the place to start before trusting any platform’s own stripping claims.

What this means if you are sharing work you made

If your goal is “I want people to know this is mine,” a screenshot gives you only the weak version: a visible notice that anyone can delete. It does not embed a machine-readable claim. The platforms that assert ownership for you do it through different machinery — YouTube’s Content ID fingerprints the audio and video, stock sites embed IPTC and watermark servers apply pixels — none of which is a screenshot. We did not test those platforms here, so we call their behaviour documented, not measured. The only thing this machine’s test proves is what a screenshot itself does: it strips the metadata and keeps the pixels.

What to actually do about it

Three situations, three answers. If you want zero metadata on a picture you share, screenshot it — that drops EXIF, XMP, IPTC and GPS in one step, because you are sharing pixels. If you want a machine-readable copyright claim to survive, a screenshot is the wrong tool; instead embed IPTC/XMP in the original file with a metadata tool, as described in clear metadata from photo — but understand that the moment someone screenshots your file, that claim is gone again. If you want a visible © that survives a screenshot, draw it into the pixels yourself; it will survive as content, but treat it as a deterrent, not a lock, because it is editable.

FAQ

Do screenshots have copyright metadata? No. We built a 1200×800 photo with an EXIF Copyright tag (7 EXIF fields total), an XMP rights packet, and a visible notice, then turned its pixels into a PNG the way every snipping tool does. The PNG came back with 0 EXIF fields, no eXIf chunk, no XMP, and no text chunk holding a copyright. Every embedded ownership claim was gone.

Does a screenshot keep the EXIF Copyright tag? No. The EXIF Copyright tag (0x8298) we wrote into the source returned the exact string © 2026 Jane Doe on read-back, and was entirely absent from the screenshot PNG. piexif could not parse any EXIF out of the PNG at all.

Does a screenshot keep XMP copyright (dc:rights)? No. The XMP rights packet we embedded was present in the source (raw-byte search found rights) and absent from the PNG — the word and the statement were both gone from the byte stream.

If my copyright watermark is still visible after a screenshot, did the copyright survive? Only as pixels, not as metadata. A visible © drawn into the image is content, and content rides along in a screenshot. It survives, but anyone can crop or paint over it, and the machine no longer asserts ownership. That is a different thing from copyright metadata.

What about IPTC copyright? IPTC copyright lives in the JPEG APP13 segment — a file-level container, not pixels — so a screenshot does not carry it either. We did not write IPTC into this test file, so we label that specific result as not-measured-here rather than claim a number we did not produce.

Do screenshots carry GPS or other EXIF then? No. A screenshot is a PNG of pixels and PNG has no EXIF container, so GPS, camera make/model, serial numbers and timestamps all drop to zero. We measured that directly in our earlier Windows Snip & Sketch run and reference it from do screenshots have exif data.