Two Redacted Versions of the Same Photo Can Leak Each Other

Start with the arithmetic, because it is the whole argument. Think of a redaction as the set of regions you covered. Version A covers set A; version B covers set B. A reader of version A can see everything outside A. A reader of version B can see everything outside B. Someone holding both sees the union of those two views — which is the entire image except the regions that appear in both sets.

So the protection you actually shipped is not the bigger redaction, and it is not the smaller one either. It is the overlap. If the two versions were redacted for different reasons, that overlap can be tiny, and in the worst case it is empty, which means the pair of files discloses exactly as much as the untouched original. This is the uncomfortable part: each version can be individually correct, reviewed, and signed off, and the set can still be a full disclosure.

The rule: your versions must nest

The fix falls straight out of the arithmetic. The combined disclosure is safe only when one redaction fully contains the other. If every region covered in the loose version is also covered in the strict version — if A is a subset of B — then the overlap is A, and someone holding both learns precisely what the loose version already told them. Nothing extra.

Extend that to three or four tiers and you get a chain: the most permissive version's covered regions sit inside the next one's, which sit inside the next one's. Every recipient sees their tier or less, and any coalition of recipients sees no more than the most permissive member of the group already had. That is the only structure that survives your files being combined, and you should assume they will be combined, because forwarding is free and case files get consolidated.

Notice what the rule forbids. It forbids two versions that each cover something the other does not. That arrangement feels balanced and even-handed, and it is the single most dangerous layout you can ship.

The reliable way to build a nested chain here

Nesting has to hold geometrically, not just conceptually. “I covered the address in both” is not good enough if the second box was drawn freehand a few pixels tighter than the first. That margin is a window, and at full resolution a few pixels of a digit or an eye is often all a reader needs.

The dependable method is to never draw the same region twice. Do it in one sitting, loosest first:

1. Open the original image once.
2. Cover only the regions that even your most-trusted recipient must not see. Download that file. This is tier 1.
3. Without clearing and without reloading the page, add the next set of boxes on the same canvas. Download again. This is tier 2.
4. Repeat for each further tier, adding regions and downloading, never removing.
5. Rename each download immediately, before the next one lands in the same folder under a near-identical generated name.

This works because of how the editor behaves: each redaction is painted onto the canvas as it currently stands, and the download reads whatever is on that canvas at that moment. Nothing resets between exports. So tier 2 is tier 1 plus more, at identical pixel coordinates, by construction rather than by your steady hand. You get the nesting guarantee for free, and you never have to eyeball whether two boxes line up.

The other direction, and why it is more fragile

You can also work strictest-first and step backwards with Undo, which restores an exact earlier snapshot of the canvas. The geometry is just as sound — it is the same pixels you had a moment ago, not a redrawn approximation.

The catch is ordering. Undo walks back through your edits in the order you made them, so it can only remove the regions you added most recently. If the boxes you want the looser version to drop are scattered through the middle of your edit history, you cannot get to them without also discarding everything after. In practice that means planning the strictest-first route in reverse tier order before you draw a single box, which is more bookkeeping than simply going loosest-first. Use it when you already built the strict version and only then discovered you need a looser one.

What you cannot do is recover the underlying content from a version you already exported. The covering is written into the pixels, and the export is re-encoded from those pixels into a new PNG, so there is no layer to switch off and no original preserved inside the file. Once the tab is closed, the route back to a looser version is the original file or nothing.

Where nesting silently breaks

Mixing modes across tiers. The whole argument assumes a covered region discloses nothing. A blurred or pixelated region is degraded, not covered, and degraded content can often still be read or recognised. If a region is blurred in tier 1 and blacked out in tier 2, tier 1 is leaking it regardless of what tier 2 does. When you are shipping multiple versions, use the black box for every region that matters, in every version.

Cropping one version instead of covering. A cropped tier and a covered tier are not nested in any useful sense — they are two different views, and combining them restores the frame. Crop and cover are different operations with different guarantees, and mixing them across a version set reintroduces the union problem through the back door.

Re-exporting from a different source file. If tier 3 was built from a re-saved or resized copy rather than the same canvas session, the coordinates can drift and the boxes no longer sit exactly where they sat before.

Someone else producing the second version. Two people redacting the same image independently will never produce nested sets. If more than one version is going out, one person builds the whole chain in one session.

Sending the wrong tier. This is the mundane one, and it is probably the most common. Several near-identical PNGs land in your downloads folder within a minute of each other under generated names that differ only by a timestamp. Rename as you go — tier1-adjuster.png, tier2-counsel.png — and attach by browsing to the file by name so you see what you are actually sending.

A release checklist

1. Before drawing anything, list your recipients and rank them from most-trusted to least. If you cannot rank them, you cannot build a chain, and you should reconsider sending more than one version.
2. Write down which regions each tier must not see. Confirm on paper that each tier's list contains the previous tier's list entirely.
3. Build all tiers in one session, loosest first, adding only.
4. Use the black box mode throughout. Save blur and pixelate for images where only one version will ever exist.
5. Rename each export as it arrives, to the recipient rather than to the contents.
6. Open the two adjacent tiers side by side at full zoom and confirm the stricter one covers every box the looser one covers, with no visible edge peeking out.
7. Keep a record of who received which tier. If a version is ever disputed, you want to know what the recipients could have pooled.

Common mistakes and misconceptions

“These two recipients will never compare notes.” Version sets get combined for ordinary, non-adversarial reasons: a case file is consolidated, a thread is forwarded, an archive is handed over, a third party is brought in and sent everything. The union is a property of the files, not of anyone's intentions.

“The stricter version protects the looser one.” It does the opposite. The stricter version tells a reader exactly which regions were worth hiding, and the looser version shows several of them.

“I will just redact it again from scratch for the second recipient.” Freehand-repeating a redaction is how slivers appear. Build the chain additively instead.

Treating a released version as a safe base. You cannot derive a looser version from a stricter export, and you should not derive a stricter version from a looser export either — the second one inherits whatever the first already gave away, and the first is already out.

Assuming a recall fixes it. Once two versions have been delivered, asking for one back does not un-combine them. The pairing is the disclosure, and it happened on delivery.

If you are producing a version set for a formal process, check each file individually before you check the set — redacting a photo used as evidence in a legal case covers what to cover and how to keep the file defensible. Then come back and check the overlap, because that is the number that decides what you actually released.