What is still in your screenshot after you crop it

A screenshot looks like the simplest possible artefact: a rectangle of pixels, exactly what was on screen. It is not. It is a container format, and containers carry things the picture does not show.

Here is what is actually in the file you are about to attach to a report.

1. Metadata you did not put there

PNG carries tEXt, iTXt and zTXt chunks. JPEG carries EXIF, XMP and IPTC. Screenshot tools and editors write into them: the capturing application and version, timestamps with timezone, colour profile, display resolution, sometimes the machine or user name, and — if the image ever passed through a phone — GPS coordinates.

Timezone alone can be enough to narrow down where a team is. Look before you send:

exiftool evidence.png
# or, without exiftool
strings evidence.png | head -40

Embedded thumbnails

The nastier variant: some formats and editors keep a small preview of the image alongside it, and that preview is not always regenerated when you edit. Crop or redact, save, and the thumbnail can still show the original frame. It is a small image, but a 160-pixel-wide preview of a terminal is often readable enough to recover a hostname.

2. Pixels you thought you removed

In 2023, CVE-2023-21036 — aCropalypse — showed that Google's Markup tool wrote cropped PNGs over the original file without truncating it. The cropped-away pixels stayed in the tail. A parallel bug hit the Windows Snipping Tool. Years of screenshots people believed were cropped could be recovered from the file itself.

The general lesson outlives the specific CVE: editing in place is dangerous. If the tool opens the file, changes part of it and writes back, whatever it fails to overwrite survives. A tool that always encodes a brand-new file from a fresh bitmap cannot have this class of bug.

Cheap check. A redacted or cropped PNG that is substantially larger than you would expect deserves suspicion, and a PNG with data after its IEND chunk definitely does. That trailing data is the aCropalypse shape.

3. Text that is still text

If your redaction is a shape drawn over content in a PDF, a slide, or a layered editor file, the content underneath is untouched. It can be selected, copied, or extracted by anything that ignores the drawing layer. This is the mechanism behind essentially every "redacted court document" story — not sophistication, just a rectangle mistaken for deletion.

The check takes one line:

pdftotext report.pdf - | grep -i "the-thing-you-redacted"
strings evidence.png | grep -i "dc01.acme.corp"

If it comes back, the redaction is decorative.

4. Content the picture shows but you stopped seeing

Not a file-format issue, but the same outcome. Everything captured alongside the thing you meant to capture:

Browser tab titles and the bookmarks bar — often the clearest inventory of internal tooling you could hand someone.
The window title bar: full file paths, ticket numbers, client names.
Notifications that arrived mid-capture.
The menu bar or system tray: VPN name, cloud tenant, the username on your own machine.
Shell prompt and scrollback above the command you cared about.

Reviewers stop seeing these after an hour of work, because they are the visual furniture around the thing being examined. That is exactly why a checklist beats attention.

What a safe export looks like

Independent of tool, three properties hold:

Fresh bitmap. The output is encoded from pixel data in which the redacted regions were overwritten — not the original file with edits layered on.
New file. Never write back over the source. This removes the entire aCropalypse class.
Metadata stripped. No EXIF, XMP, text chunks or thumbnails carried across.

Then verify, because the point of the three properties is that they are checkable:

strings out.png | grep -i "secret-string"   # nothing
exiftool out.png | head -40                # nothing interesting
pdftotext report.pdf - | grep -i "secret"  # nothing

Blackbar is built around exactly those three properties — export rasterises the source, overwrites the redacted regions in a new bitmap, encodes a new image and strips all metadata, with a test in the build that reads exported files back and asserts the original content is gone. But the checks above work against any tool, and running them once on your current workflow is worth more than trusting any claim, including ours.