BASALT · JOURNAL
A black box over text is not a redaction
The instinct to black out text in a PDF comes from paper. On paper, a marker deposits ink on fibers and the letters underneath are physically destroyed. On a screen, the black box is a drawing instruction and the letters are data. The instruction does not touch the data.
Every recovered redaction you have read about follows from that one mismatch. Somebody applied a paper mental model to a file format that does not work like paper.
The rendering order illusion
A PDF page is a program. The content stream is a list of operators executed in sequence: set a font, set a text matrix, show a string of glyphs, set a fill color, define a path, fill it.
A viewer runs that program top to bottom and paints as it goes. Text drawn early gets covered by a rectangle drawn late. What you see is the final state of the canvas after every instruction has run.
The file, meanwhile, contains every instruction. The text-showing operators, Tj and TJ and their relatives, still hold their character code arguments. The fill operators that produced the box are separate instructions that happen to come later. Nothing about the box modified the text.
So there are two different things going on and they are easy to conflate. The rendered page is the output of a computation. The PDF is the source code. Redaction has to happen in the source.
Annotations make it worse
Often the box is not even in the content stream. Markup tools in Preview, in Mail, in most viewers, and in many browser PDF plugins create annotation objects: dictionaries in the page's /Annots array with a rectangle, a color, and an appearance stream.
Annotations were designed to be removable. That is their purpose. A reviewer adds a comment, another person deletes it. A square annotation used as a redaction is a comment shaped like a rectangle, and any tool that can delete a comment can delete it.
You can strip every annotation from a PDF with a handful of lines of code. There is no security boundary there, because none was ever claimed. The tool did what its documentation says it does.
Where the words are still sitting
Suppose you flatten the box into the page so it is no longer an annotation. The visible glyphs are still under it, and there are several more places the same words live that no box was ever drawn over.
Scanned documents almost always carry an OCR text layer: invisible text drawn in rendering mode 3, positioned to match the picture of the words, so the file is searchable. Black out the image and the invisible text layer under it is untouched and fully extractable.
/ActualText and /Alt entries store a plain text equivalent of a marked content span for accessibility. A name excised from the visible glyph run can remain in /ActualText, and screen readers and extraction tools will read it.
Form field values live in the field dictionary, not in the page content. Covering a widget's appearance leaves the value in place. Annotation /Contents strings, the text of a sticky note or the value of a free text annotation, are stored as plain strings.
Optional content groups, the layers feature, let content be marked as belonging to a group that can be switched off. Invisible on screen, entirely present in the file. Then there are page thumbnails cached before your edit, embedded file attachments, and the document's own metadata. That set is covered in what a PDF still carries after you think you cleaned it.
Why the visual result tells you nothing
Here is the part that matters for anyone signing off on a production. The appearance of the page carries no information about whether a redaction succeeded.
A correctly redacted file and a file with a rectangle drawn on it look identical. Both show a black bar where a name used to be. There is no visual difference, at any zoom level, on any display. Rendering is exactly the step that hides the distinction you care about.
That means visual review, which is what most document review workflows actually do, cannot catch this class of error. A careful reader checking every page will pass a completely unredacted document, because the pages look fine. The failure is silent by construction.
Any process that ends with "someone looked at it" is not a redaction process. The check has to read the file, not the picture.
What has to be destroyed
Removing a word properly means editing the content stream. The text-showing operators have to be parsed and resolved into individual glyph runs with real page positions, accounting for the text matrix, font size, horizontal scaling, character and word spacing, and TJ kerning adjustments. A single TJ array usually holds a full line, so the operation is per glyph, not per operator.
The covered glyphs are excised and the surviving glyphs are re-emitted at their original positions, because half a line still has to render exactly where it did before. If the sensitive content is pixels rather than glyphs, the pixels under the mark must be overwritten in the image data and the image re-encoded, otherwise the original image object is extractable whole.
Then the file has to be written as a single generation. PDF allows incremental updates where a new revision is appended and the old bytes remain. Save a redaction that way and the pre-redaction page is still physically in the file, recoverable by walking the update chain. This is one of the reasons redacting in Preview is not redaction.
The right standard to hold
Ask for evidence, not assurance. A tool telling you the redaction is done is a statement about its intent. Evidence is an independent parser reading the written bytes and reporting that the terms are absent from the content streams, the annotation values, the form fields, the accessibility text, and the metadata.
Reproducibility helps too. If the same source file plus the same marks produces a byte-identical output every time, a third party can re-run it and confirm your result rather than take your word. How to check whether a PDF was really redacted walks through the checks you can run yourself.
Frequently asked questions
Does drawing a black box over text in a PDF remove the text?
No. The black box is a separate drawing instruction added to the page, and the text-showing operators that hold the original characters remain in the content stream unchanged. A viewer paints the box after the text, so the words disappear visually while staying fully present in the file. Anyone can extract them with text selection or a command line parser.
Can someone recover text hidden under a black rectangle?
Yes, usually in seconds. Selecting the area and copying often reveals the text directly, and a parser reading the content stream will recover it even when copy and paste fails due to a missing font mapping. If the box was added as an annotation, deleting the annotation restores the page to its original appearance.
Is there a visual way to tell a real redaction from a fake one?
No. A properly redacted page and a page with a rectangle drawn over the text look identical at every zoom level on every display. That is why page-by-page visual review cannot catch this error. The only reliable check reads the file contents with a parser rather than looking at the rendered image.
Does flattening a PDF make a black box permanent?
Flattening destroys the visible text under the box, but it is not a complete redaction. It leaves metadata, XMP packets, embedded attachments, form field values, and any earlier revisions in the incremental update chain untouched. It also usually rasterizes the page, which removes the searchable text layer from the entire document.
Why do redacted court filings keep getting uncovered?
The pattern is almost always the same mechanism: a rectangle drawn over text that was never removed from the content stream. The filer used a tool that draws shapes, saw a black bar on screen, and had no signal that the underlying data survived. Reporters then recover the text by copying and pasting from the published file.
Does a black box protect a scanned document?
Not by itself. Scanned pages usually carry an invisible OCR text layer drawn in rendering mode 3 to make the file searchable, and a box over the picture leaves that text layer intact and extractable. The image pixels themselves also remain in the original image object unless they are overwritten and the image is re-encoded.
Is highlighting in white the same as blacking out?
White is worse, and it fails the same way. Painting a white shape over text, or setting the text color to white, leaves the characters in the content stream and adds the risk that a reader will not even realize a redaction was attempted. Selecting the page text reveals everything.
Doing it in Basalt
Basalt treats a mark as an instruction to destroy, not to draw. Text is excised from the content stream glyph by glyph and the surviving text is re-emitted in place, image pixels under a mark are destroyed and re-encoded, and metadata, XMP, attachments, hidden layers, and stale thumbnails are stripped. The file is written as one generation so earlier versions cannot be recovered.
A built-in verifier re-opens the written file with an independent parser and proves the redaction before anything is saved. If it cannot prove it, no file is written at all. You get an Ed25519-signed certificate of redaction that anyone can verify with shasum and openssl, with no copy of Basalt required.
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.