BASALT · JOURNAL

Why redacting a PDF in Preview is not redaction

2026-08-06 · redact pdf in preview mac

Preview is the default PDF application on every Mac, it opens instantly, and it has a rectangle tool that draws a filled black box. That combination has produced more accidental disclosures than any other piece of software on the platform. When you redact a PDF in Preview on Mac, the words under the box are still in the file.

This is not a bug and it is not a version-specific problem. Preview is a viewer with annotation features, and annotation is an additive operation by design.

What the black rectangle actually is

Preview's shape tool creates either a square annotation object or, after certain export paths, a set of path-painting operators appended to the page's content stream. Both are additive.

An annotation is a dictionary attached to the page with a rectangle, a color, and an appearance stream describing how to draw it. It sits in the /Annots array. The page content underneath is untouched, which is the entire point of annotations: they are supposed to be removable comments layered over a document.

The painted-path version is barely different in effect. The page content stream already contains the text-showing operators for the sensitive words. Preview appends fill operators after them. A renderer executes the stream in order, so the rectangle paints last and covers the text visually. The Tj and TJ operator arguments carrying the character codes are still there, in the same positions, in the same stream.

Any tool that reads the content stream instead of looking at the rendered page will find them. That includes the text selection in Preview itself, pdftotext, Spotlight's indexer, and every ediscovery platform your document is likely to pass through.

The test that takes ten seconds

Open the file you redacted. Drag-select across the black box. Press Command-C. Paste into TextEdit in plain text mode.

If the text you thought you removed appears in the paste, it was never removed. On many Preview-produced files it does appear, immediately, with no tools and no expertise required. This is the same mechanism behind the well-known pattern of court filings and government releases where reporters recovered redacted names by copying and pasting from the published PDF.

The uncomfortable part is the inverse case. If nothing pastes, that does not prove the file is clean. Copy-paste failure can come from a broken font encoding, a missing /ToUnicode map, or a viewer quirk, while the character codes and the glyph runs remain fully present and recoverable by a parser that maps fonts directly. Passing the paste test is necessary, not sufficient. How to check whether a PDF was really redacted covers the checks that actually settle it.

Flatten and print to PDF

The common advice when someone learns that annotations are not redaction is to flatten the file: print to PDF, or export in a way that bakes annotations into the page.

This does work on the narrow question. Printing rasterizes or regenerates the page, and the text under the box does not survive that. But it is a blunt instrument with real costs.

You lose the text layer across the entire document. The file is no longer searchable, no longer selectable, and no longer accessible to a screen reader. Bookmarks, tagging, and form structure are gone. For anything filed with a court that requires text-searchable PDFs, or anything that has to be produced in a searchable format under a discovery protocol, that is a failing document.

You also usually get a larger file, because a page of crisp text becomes a page of pixels.

And crucially, printing does nothing about the rest of the file. The document information dictionary and the XMP packet ride along or get regenerated with the same author name. Embedded attachments may be dropped or may not. If the original was assembled from several files, an unflattened annotation elsewhere in the document is not caught by the one page you were worried about. Rasterizing is a side effect that happens to destroy some text. It is not a redaction procedure.

What Preview does not touch at all

Even if the visible text problem were solved, a redaction is a claim about the whole file. Preview has no interface for most of what that claim covers.

There is no way to inspect or strip the XMP metadata packet, which routinely carries the author, the originating application, a document identifier that links the file to its ancestors, and a history of edits. There is no way to list or remove embedded file attachments, which can be an entire spreadsheet hidden inside the PDF. There is no view of optional content groups, the layers mechanism, where a turned-off layer is invisible on screen and fully present in the file.

There is no handling of /ActualText, the accessibility field that stores a plain text equivalent for a span of content. A word can be excised from the visible glyph run and remain readable in /ActualText.

There is no control over form field values, which persist in the field dictionary regardless of what is painted over the widget. And there is no view of the incremental update chain, which matters more than any of the rest.

Incremental updates keep your earlier drafts

PDF was designed so a file can be updated by appending. A new set of objects and a new cross-reference table go at the end, and the original bytes stay exactly where they were. Viewers read the newest cross-reference table and show you the current state.

Preview saves edits this way in many situations. That means a file you edited three times contains three versions of the affected objects. Walking back through the update chain, which is a documented and entirely mechanical operation, reconstructs earlier states of the page.

If an earlier state had the text uncovered, which is by definition the state before you drew the box, then the unredacted page is physically present in the file you emailed. No amount of black rectangle is relevant at that point.

A real redaction has to be written as a single generation, with one cross-reference structure and no retained prior revisions. That is a file-writing decision, not something you can apply after the fact from a viewer.

What to require from a tool instead

The bar is straightforward to state. The tool must parse the content stream and remove the covered glyphs from the text-showing operators, then re-emit the surviving glyphs at their original positions so the rest of the line still renders correctly. It must destroy and re-encode image pixels under a mark rather than painting over them. It must strip metadata, XMP, attachments, hidden layers, and stale thumbnails. It must write one generation.

And it must let you verify the result with something that is not itself. A tool's own confirmation dialog is a statement of intent, not evidence. See a black box over text is not a redaction for why the visual result is the least informative signal available to you.