Sending Two Different Redacted Versions of the Same PDF
Sometimes one recipient is entitled to more of a document than another, so you produce two releases from one source. Each one can be perfectly redacted and still be a disclosure, because the two copies can be put side by side and subtracted from each other.
Most of the guides on this site examine a single file. Is the text really destroyed under the box. Can OCR recover it. Does the metadata name you. Did you pick the right file out of the two in your folder. All of those are questions about one document and one recipient.
This page is about a different situation: you are deliberately producing more than one redacted version of the same source, because different recipients are entitled to different amounts of it. The requester gets one. Opposing counsel gets a fuller one. The board gets almost everything. Each version, examined on its own, is competent work. The problem is that nobody examines them on their own forever. Versions meet — in a public docket, in a published disclosure log, in a shared inbox, between two people who both received something and compare notes. The moment two differently redacted copies of one document are in the same hands, the recipient learns more than either copy was meant to show.
Why two versions leak more than either one alone
The mechanism is subtraction, and it is unforgiving. Suppose a page contains a name, a dollar figure and a date. Version A covers the name because the requester is not entitled to identities. Version B covers the figure because the committee is not entitled to the settlement amount. Both decisions are correct in isolation. Anyone holding A and B reads the name from B and the figure from A, and has the complete page.
It gets worse than simple subtraction, because the two copies also reveal the shape of your judgment:
The difference map is the index of what is sensitive. Comparing the copies tells a reader not only what was withheld but which items you considered sensitive enough to withhold from whom. That is a map of your reasoning, and in an adversarial setting it is an argument you did not intend to make.
A box in one version localises content in the other. If version B leaves a paragraph intact and version A covers four words in the middle of it, the reader of both knows precisely which four words of a sentence they already have were the sensitive ones — a far sharper result than either copy gives alone.
Partial overlaps confirm guesses. A reader who suspects a figure can test the suspicion against the copy that shows it. Suspicion becomes confirmation, and confirmation is what actually causes harm when the withheld item is a person's identity or a medical fact.
Pagination and structure align perfectly. Two exports from the same source have the same page count, the same page sizes and the same layout, so the comparison needs no effort or skill. Put the two files side by side at the same zoom and the differences are obvious to the naked eye.
There is a second-order version of this that is easy to miss: the two copies do not have to be yours. If you release a fuller version to a party who is themselves obliged to publish it, or who releases their own copy later, your narrow version is now comparable with something you did not send. The question is never "will I release two versions" — it is "what else about this document is or will be in circulation".
The nesting rule
The rule that prevents all of the above is simple to state and should drive the whole workflow: redaction sets across versions must be nested. Every item covered in a more generous version must also be covered in every less generous version. Written as a test: if you arrange your releases from most-disclosed to least-disclosed, the black boxes must only ever be added going down the list, never swapped or moved.
What the rule forbids is crossing — covering item X here and item Y there. Crossing is what makes two copies subtractable. Nesting means the narrower copy shows strictly less, so comparing them tells a reader only that the narrow copy is narrower, which they already knew.
In practice this means tiers cannot be reviewed independently. Produce them from one decision list:
- Inventory the sensitive items once, on the source document. Go through the unredacted original and list every item that could be withheld from anybody — name, account number, address, amount, date, clinical detail, third-party identity. Number the list.
- Decide the audiences and order them. Write down every recipient who will receive a version, and rank them from most entitled to least entitled. If you cannot rank two recipients, treat them as one tier and give them the same file.
- Assign each item to the highest tier that may see it. Item 4 is visible to counsel and above; item 7 is visible to nobody outside. Each item gets one answer, not one answer per version.
- Check that the tiers nest. Read down the list: each tier's box set should be the tier above it plus some additions. Any item marked visible in a narrower tier and covered in a broader one is a crossing, and it must be resolved by covering it in both.
- Produce every version from the original, in tier order. Start with the most generous release, then make the next by adding boxes — not by editing a previous export. A redacted export has had its content destroyed, so you cannot work forward from it, and trying produces inconsistencies.
- Check the additions, not the whole document, on each subsequent tier. The page-by-page review still matters, but the specific thing to verify on tier two is that everything tier one covered is still covered.
- Record which tier went to which recipient. Without that record you cannot answer, later, whether a new release nests inside what someone already holds.
If the nesting check fails and you cannot resolve it — because one recipient is genuinely forbidden from seeing what another is genuinely entitled to, in both directions — then the honest conclusion is that this document should not be released in two tiers. Split it instead: send different parts of the document to different recipients, or produce separate documents, so there is no single page whose two renderings can be subtracted.
Where the tool on this page fits
A few specifics are worth knowing if you are producing tiers with HidePDF, all of them verifiable in the client-side code this page loads.
The boxes you draw are burned in: the export re-renders every page to an image with your black rectangles painted on, and assembles those images into a brand-new PDF. Nothing is copied from the original document's internals, so neither tier carries a text layer, an annotation you could toggle off, or the original's metadata — the output's title is set to "Redacted Document" and its producer and creator to "HidePDF". That is what you want for tiered work: there is no hidden original inside the generous copy for the narrow copy's recipient to find.
Because every export is rendered at a fixed internal scale with one output page per input page at the original dimensions, two tiers made from the same source come out structurally identical — same pages, same size, same position of everything. This is the right behaviour, and it is also exactly why the comparison between tiers is trivial to perform. Do not treat structural sameness as a leak to be hidden; treat it as proof that the nesting rule is doing all the work.
Boxes are placed by hand, per page, and there is no find-and-cover-everywhere function. For tiered releases that is a practical constraint worth planning around: your numbered decision list is the thing that keeps tier two consistent with tier one, since the tool will not remember tier one's boxes for you. Each tier is a fresh pass over the original with the list in front of you.
All of it runs locally in your browser tab, with no upload required, which matters here more than on a single-file job. Producing three tiers means opening the unredacted original three times, and the original is the most sensitive artefact in the whole exercise.
Common mistakes and misconceptions
Reviewing each version independently. Two careful, separate reviews are precisely how crossings get created, because each pass optimises for its own audience. One list, many tiers.
Making the narrow version by un-redacting the broad one. You cannot. The content under a burned-in box is gone, and anything you build from an export will be missing content the broader tier was supposed to show. Every tier comes from the original.
Assuming recipients will not compare. Comparison does not take a specialist. Dockets are public, disclosure logs get published, recipients forward things, and the two files line up page for page.
Treating a later, fuller release as unrelated to an earlier one. An appeal or a second request often results in a less-redacted copy months later. That copy must nest with the one already issued, which means you need to know what the first one covered.
Relying on different file names to keep tiers apart. Suffixes like -v2 or -full sit at the end of a name, which is where file lists and attachment chips truncate. Mark the audience, and mark it at the front.
Varying box sizes between tiers. Covering a name with a tight box in one version and a generous one in another tells a reader the length of what is underneath. Where an item is covered in more than one tier, cover it the same way.
Forgetting that totals cross tiers too. If the broad version shows a subtotal and the narrow version covers the line items that sum to it, the arithmetic can reconstruct them. Nesting has to apply to derived values, not just to the characters you blacked out.
Letting someone else produce tier two. If a colleague makes the second version without your decision list, they will redact to their own judgment, and their judgment will cross yours somewhere. Hand over the list, or do both tiers yourself.
Related guides
See also, or use the redaction tool above:
- Keeping the redacted and unredacted versions of a PDF straight
- Redacting numbers when the totals give them away
Frequently asked questions
If each version is defensible on its own, why is releasing both a problem?
Because the thing a recipient holds is not one version, it is the set of versions they can obtain. Defensibility is usually assessed one document at a time: every box in this copy covers something I was entitled to withhold. That test passes for both copies even when the two copies, read together, disclose everything. If the copy sent to a requester covers the amounts but leaves the names, and the copy sent to a committee covers the names but leaves the amounts, then anyone holding both reads a complete document — and so does anyone to whom either holder forwards their copy. Nothing about this is a failure of your redaction technique. It is a failure to treat the releases as a set, which is why the fix is a single decision list applied to every tier rather than two separate review passes.
Is the safe answer just to redact more in every version?
Issuing one maximally redacted copy to everybody does close the comparison gap, and when the tiers are close together it is often the right call — the cost of handing one recipient slightly less than they were owed can be much lower than the cost of a reconstructable pair. But flattening every tier to the strictest one is not free. Over-covering makes a document unusable, invites challenges and appeals that reopen the whole exercise, and in some settings withholding more than you are permitted to withhold is itself the violation. The narrower rule is the nesting rule: you can release different amounts, as long as every item covered in a more generous copy is also covered in every less generous copy. That lets a requester receive less than a regulator without the two copies being able to be subtracted from one another.
Does the export from this page make two versions easier to compare?
It makes the comparison mechanical, yes, and that is worth knowing rather than worrying about. The export rebuilds every page as an image at a fixed internal scale and writes one output page per input page at the original page dimensions. Run the same source PDF through twice with different boxes and the two files are the same size and shape page for page, so an ordinary image-difference check lights up exactly the regions you treated differently, with no alignment work needed. The redaction itself is not weakened by this: the covered pixels are gone from both files and neither export carries a text layer, so a diff tells someone where the versions disagree, not what was underneath. Worth noting too that a diff is not what makes a tiered release leak — reading both copies side by side does that, and a person can do it unaided. Assume the comparison will happen and build the versions so that it yields nothing.
How should I keep track of which version went to whom?
Name each export for its audience rather than its sequence — released-public, counsel-only, board — and put that word at the front of the filename where a narrow file list cannot truncate it. Then keep a one-line record per release: date, recipient, which tier, and which decision-list items that tier covers. Two things make this worth the few minutes it costs. If a further release is requested later, the record tells you which tier it must nest inside instead of forcing you to reverse-engineer your own boxes from a flattened file. And if someone ever asks whether two of your releases could be combined, the answer is a lookup rather than a memory test. A version number alone will not do this job, because v2 does not say who holds v1 or how much it showed.