BASALT · JOURNAL
Preserve the original when redacting a PDF
Redaction is intentionally destructive, which is precisely why it should never be performed on the only copy. A clean file-handling pattern protects the evidence, prevents accidental disclosure, and lets another person reproduce what happened.
Use three distinct states
Keep a source copy exactly as received, a working copy containing marks and review state, and a release copy in which approved content has been destroyed. Put them in separate folders with access appropriate to each state.
Names should communicate state without depending on color labels or Finder tags. For example:
source/Smith_Statement_received_2026-09-18.pdf
working/MATTER17_Statement_redaction-review.pdf
release/MATTER17_Statement_PUBLIC.pdfAvoid names that contain sensitive information in the release folder. Filenames can appear in email systems, download logs, and document metadata even when the pages are clean.
Hash the source and release
A cryptographic hash is a fingerprint of the exact bytes. Record a SHA-256 hash when the source enters the workflow and another for the approved release. The hashes do not prove that the redaction is correct; they prove which exact files were reviewed and sent.
If any later step combines, compresses, signs, or stamps the release, the bytes change and it becomes a new candidate. Verify it again and record the new hash.
Keep editing away from the source
Open the source read-only where practical and export to a new path. Do not use “Save” over the received file. Incremental PDF saves may append a new revision while leaving old objects in the same file, so safe redaction should rewrite one clean generation rather than accumulate history.
Backups of the source remain sensitive. Limit access and retention under the same rules as the original material; a perfectly redacted public copy does not reduce the risk in an old Time Machine or cloud-sync version.
Release by exact hash
The review record should name the release filename, size, page count, and hash. The sender compares the outbound file to that record immediately before transmission. This simple step catches mix-ups between FINAL, FINAL2, and an unredacted source more reliably than visual confidence.
Pair this with a redaction quality-control workflow for content checks.
Frequently asked questions
Why not redact the original PDF directly?
Mistakes, software failures, and later questions require an unchanged reference. Redaction is destructive and should produce a separate release artifact.
Does a file hash prove a redaction is safe?
No. It identifies exact bytes. Safety comes from review and verification; the hash lets you prove the file sent is the one that passed those checks.
Should the unredacted original be deleted afterward?
Follow the applicable retention, evidence, privacy, and legal-hold policy. Do not delete it merely because a redacted copy exists, and do not retain it casually either.
Doing it in Basalt
Basalt writes redactions to a new file, rewrites one clean PDF generation, verifies the output independently, and can produce a signed certificate tied to the source and output hashes. The original remains untouched and all processing stays on the Mac. Get Basalt.
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.