BASALT · JOURNAL
Verifying a redaction on a very large file
Verification is the step most often skipped on large jobs, on the assumption that checking a thousand pages must be expensive. It is not. Verification reads text and structure rather than rendering pages, and both are cheap.
What it costs
Extracting text from a 2,000 page document and searching it measured at 0.24 seconds. Structural checks, counting revisions, reading metadata, listing attachments, are similarly inexpensive because they inspect the file's tables rather than its content.
Against a sixteen minute scanned redaction run, verification is a rounding error. There is no performance argument for leaving it out.
What a verifier should check
That the removed terms are absent from extracted text, using a parser independent of the one that wrote the file. Checking your own output with your own reader shares any assumption that caused the bug.
That the document is a single generation, with no earlier revision retained. An incremental save can leave the unredacted page intact earlier in the file.
That metadata, XMP, attachments, embedded scripts and hidden optional content are gone, since these are the leaks that do not appear on any page.
That the invisible OCR text layer, if there was one, no longer contains the removed terms.
Before writing, not after
The important design detail is when verification runs. A check after the file is saved tells you a bad file exists and now needs deleting, which relies on somebody acting on the warning.
A check before the file is written can refuse to produce it at all. The failure mode becomes no output rather than a quietly bad output, and on a large production that difference matters because nobody re-reads a thousand pages to catch what a warning mentioned.
Verifying somebody else's file
The same checks work on a document you received. Extract the text and search it, count the %%EOF markers to see whether earlier revisions survive, read the metadata, and list any attachments.
This is worth doing on incoming productions as a matter of course. Finding that an opponent's redaction failed is useful, and finding that your own vendor's did is considerably more useful before you pass it on.
Frequently asked questions
Does verifying a redaction take long on a large PDF?
No. Verification reads text and file structure rather than rendering pages, so it costs seconds even on very long documents. Extracting and searching the text of a 2,000 page document measured at 0.24 seconds.
What should a redaction verifier check?
That removed terms are absent from extracted text using an independent parser, that the file is a single generation with no earlier revision retained, that metadata, XMP, attachments and scripts are stripped, and that any invisible OCR text layer no longer contains the removed terms.
Why should verification run before the file is saved?
Because a check afterwards produces a bad file plus a warning, and warnings get missed. A check beforehand can refuse to write the file at all, so the failure is a missing output rather than a document that looks finished and is not.
Can I verify a redaction someone else performed?
Yes, with the same methods. Extract the text and search for terms that should be absent, count %%EOF markers to detect retained earlier revisions, read the metadata, and list attachments. It is worth doing routinely on incoming productions.
Doing it in Basalt
Basalt is a native macOS PDF toolkit with eighteen tools in one window. It opens large documents without loading them into memory, renders pages on demand, and copies files into its engine in fixed-size chunks, so peak memory follows the chunk size rather than the file size. Redaction destroys content rather than covering it, and an independent verifier re-opens every written file to prove the material is gone before the file is saved. A one time $29 licence covers up to three Macs, it is free for the first 24 hours, and the engine holds no network entitlement at all, which macOS enforces at the code-signature level. Download it at basaltformac.com.
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.