BASALT · JOURNAL
The checklist to run before you file a redacted document
Redaction failures are almost never caused by someone not knowing that redaction matters. They are caused by a competent person under deadline who did the visible part, saw black boxes on the screen, and had no signal telling them the file was still carrying the text.
What follows is a sequence you can run in order. It assumes you have a document ready to file and a set of things that must not appear in it. Steps 1 through 5 are preparation, 6 through 12 are verification of the written file, and 13 through 15 are the record.
Before you mark anything
1. Work from a copy, and keep the original untouched.
Redaction is destructive. You need the original both to re-run the work if a mark was wrong and to let a reviewer reproduce the result later. Store it somewhere the redaction workflow cannot write to, and record its SHA-256 now:
shasum -a 256 original.pdf2. Inspect the file before you decide what to do to it.
Find out what the document actually carries before you start. You are looking for embedded attachments, an XMP metadata packet, optional content groups (layers), annotations, form fields, an OCR text layer behind scanned pages, and page thumbnails. The answer changes your plan: a scan with an OCR layer needs both pixel and glyph handling, and a file with attachments needs those removed regardless of what is on the pages.
The full inventory of what hides where is in what a PDF still carries after you think you cleaned it.
3. Define the categories, not just the instances.
Write down what is being removed and why: names of minors, account numbers, home addresses, privileged communications, health information. Categories catch the instance you did not notice, because you can search for the pattern rather than relying on having read every page.
This list also becomes the basis of your privilege log and your production letter.
4. Search for each category rather than reading for it.
Use text search across the whole document for each category. Account numbers and identifiers have shapes you can search for. Names appear in headers, footers, exhibit stamps, and signature blocks that the eye skips. Search for the same string with and without spaces and punctuation, since a number may be broken by a TJ kerning array in a way that defeats a naive search in some viewers.
5. Check the places that are not the page body.
Bookmarks and named destinations frequently carry section titles containing a name. Form field values persist even when the field is not visible. Annotation contents, including sticky notes and the appearance streams of stamps, carry text. Optional content groups that are switched off render nothing and still hold everything. Attachments are whole separate files.
Apply the redaction
6. Use a tool that destroys rather than covers.
The mark has to result in glyphs being excised from the content stream with surviving glyphs re-emitted in place, and image pixels under the mark being overwritten and the image re-encoded. Drawing a filled rectangle appends operators and leaves everything underneath. If your tool's redaction is indistinguishable from its shape tool, it is a shape tool. The mechanism is spelled out in the black box myth.
7. Strip metadata, attachments, layers, and thumbnails in the same operation.
The document information dictionary, the XMP packet, embedded files, hidden optional content groups, and stale page thumbnails all have to go. A thumbnail is a picture of the page as it was before your edit, and it is not regenerated automatically.
8. Confirm the file was written as a single generation.
PDF supports incremental updates, where a new revision is appended to the end and the previous bytes remain. Saved that way, the pre-redaction version is still physically in the file and recoverable by walking the update chain. The output must have one cross reference structure and no prior revisions.
A quick smell test: search the raw file for occurrences of %%EOF. More than one is a strong indication of an update chain.
Verify the written file
Do all of the following against the saved output, using tools other than the one that wrote it. Verification by the writer is a self report.
9. Extract the text with an independent parser and search it.
pdftotext -layout redacted.pdf - | grep -i "smith"Run this for every category term from step 3. pdftotext reads the content stream directly rather than showing you a rendering, so it sees what a viewer would let someone copy. Zero hits is the only acceptable result.
10. Extract every image and look at all of them.
pdfimages -all redacted.pdf /tmp/out/Open each extracted file, including the small ones, which is where thumbnails appear. Extracted images are at native resolution, often much higher than what you saw on screen, so check whether something you judged illegible at page zoom is legible at 600 DPI. Details are in redacting images inside a PDF.
11. Check the metadata separately.
Text extraction does not show you an XMP packet, a document information dictionary, or an attachment. Inspect those explicitly and confirm the author, title, subject, keywords, producer, and original file path are gone or intentionally set.
12. Do the copy and paste test as a final sanity check.
Open the file in a viewer, select across each redacted region, copy, and paste into a plain text editor. This catches the crudest failure and takes ten seconds. It is not sufficient on its own, because it will not reveal an attachment, a hidden layer, or an OCR text layer that your selection did not cover. The complete procedure is in how to check whether a PDF was really redacted.
If any of steps 9 through 12 finds something, go back to step 6 with the original. Do not repair the redacted output, because you would be adding a second generation to a file you just established has a problem.
Record what you did
13. Hash the output and record it.
shasum -a 256 redacted.pdfKeep this with the matter file. If the document that surfaces later does not hash to this value, it is not the file you produced, and you can say so with specificity.
14. Keep a certificate that a third party can verify.
A signed record tying the output hash to the mark count and the checks that passed is what turns "we redacted it properly" into something checkable by someone who does not have your software. What makes one credible is covered in certificates of redaction.
15. Preserve the marks and the original together.
If your tool produces byte identical output for the same inputs, the original plus the mark record lets anyone reproduce the exact file you filed. That is the strongest form of the claim you can make, and it is discussed in reproducible redaction.
Before it goes out the door
Two last checks that catch real errors.
Compare page counts between original and output. A page dropped in processing is a production error that is easy to miss and awkward to explain.
Look at the file size. A redacted scan should differ meaningfully in size because image objects were re-encoded. An output a few hundred bytes larger than the input almost certainly just gained rectangles.
Frequently asked questions
What should be on a redaction checklist before filing?
Work from a copy and hash the original, inspect the file for attachments, layers, OCR text and thumbnails, define the categories being removed, search for each one rather than reading for them, apply a tool that destroys rather than covers, strip metadata, then verify the saved output with an independent text extractor and image extractor before recording the output hash.
How do I check that a PDF redaction actually worked?
Run an independent parser against the saved file rather than trusting the app that wrote it. Use pdftotext -layout and grep for every term you removed, then pdfimages -all to dump every image object and look at each one. Inspect metadata separately, since text extraction will not reveal an XMP packet or an embedded attachment.
Is the copy and paste test enough to confirm a redaction?
No. It catches the crudest failure, where text still sits under a drawn rectangle, and it misses everything else. It will not reveal an embedded attachment, a hidden optional content group, an OCR text layer your selection did not cover, or metadata carrying the original author and file path. Treat it as a ten second sanity check, not as verification.
What do I do if verification finds remaining text?
Go back to the untouched original and redo the redaction there. Do not patch the redacted output, because saving again on a file you just proved is defective adds a second generation and leaves the earlier revision recoverable in the update chain. This is the main reason the checklist starts by preserving an untouched original.
How can I tell if a PDF was saved as an incremental update?
Search the raw file for %%EOF and count the occurrences. More than one strongly suggests an update chain, which means one or more earlier revisions are still physically present in the file and can be recovered by walking backward through the cross reference sections. A properly redacted file is written as a single generation.
What gets missed most often in redaction?
The places that are not the page body: bookmarks and named destinations carrying section titles, form field values that persist when the field is not visible, annotation contents and stamp appearance streams, optional content groups switched off, embedded attachments, and stale page thumbnails showing the page as it was before the edit.
Should I compare page counts and file size before filing?
Yes, both catch real errors quickly. A page count mismatch between the original and the output means a page was dropped in processing, which is awkward to explain after production. A redacted scan should differ meaningfully in size because image objects were re-encoded, so an output only a few hundred bytes larger than the input probably just gained rectangles.
Why should I hash the file before I send it?
Because it lets you distinguish later between a redaction that was wrong and a document that was altered after you produced it. If a file surfaces months later and does not hash to your recorded value, something re-wrote it, and you can say so with specificity and produce your copy.
Doing it in Basalt
Basalt is built so that most of this checklist is not optional. The Inspector reports what a PDF still carries before you start: metadata, attachments, hidden layers, annotations, and OCR layers. Redaction excises text from the content stream glyph by glyph, destroys and re-encodes image pixels under a mark, strips metadata and thumbnails, and writes as one generation.
Steps 9 through 12 happen automatically: a built in verifier re-opens the written file with an independent parser and proves the redaction before anything is saved, and if it cannot prove it, no file is written and it tells you why. You get a signed Ed25519 certificate with the SHA-256, the mark count, and the checks that passed, plus byte reproducible output.
The engine runs as a separate process with no network entitlement, enforced by macOS at the code signature level. It is $29 once for up to three Macs, free for 24 hours, and a 17 MB download.
Redaction that proves itself
Basalt destroys the content you mark, then re-opens the file it wrote and proves the content is gone before it saves anything. Your documents never leave your Mac.