BASALT · JOURNAL
Disk space, not memory, is the real cost of large PDFs
An application that handles very large documents gracefully has usually traded a memory problem for a disk one. That is the right trade, and it introduces a cost that is easy to overlook until a drive fills up during a production run.
What a working copy is
Editing a document safely means never writing to the original while work is in progress. The usual approach is to copy the file into a working area, operate there, and write the result somewhere new. The original is untouched throughout, which is what you want when the original is evidence.
The consequence is that opening a 2 GB document can consume 2 GB of working space, and a job that produces an output needs room for that too.
The arithmetic for a production
Take a 1 GB scanned production being redacted. You need the original at 1 GB, a working copy at 1 GB, and an output that may be smaller or larger than the input depending on how the images re-compress. Budget two and a half to three times the input size in free space.
That is comfortable on most machines and tight on a MacBook Air that is already full of everything else.
Where the space goes and when it comes back
Working copies should be released when a document is closed. It is worth checking this on whatever you use, because an application that leaks working copies will quietly consume tens of gigabytes over a few weeks of document work.
Look in the application's container under ~/Library/Containers for sandboxed applications. Files accumulating there long after the documents were closed indicate cleanup that is not happening.
Practical rules
Keep more free space than you think you need before a large run. Running out mid job is recoverable but wastes the whole run.
Work from an internal drive rather than a network volume. Reading and writing a working copy over a network is slow enough to change a sixteen minute job into an afternoon.
Do not point a large job at an external drive that spins down. Idle timeouts during a long run produce failures that look like corruption and are not.
Frequently asked questions
How much free disk space do I need to edit a large PDF?
Budget roughly two and a half to three times the input size. The original, a working copy, and the output all occupy space at once, so a 1 GB production is realistically a 3 GB job.
Why do PDF applications copy the file before editing?
So the original is never modified while work is in progress. That matters when the original is evidence, since a crash mid edit must not damage it. The copy is the cost of that safety.
Where do PDF working copies get stored?
For sandboxed macOS applications, inside the application's own container under ~/Library/Containers. Files that persist there after documents are closed suggest working copies are not being cleaned up.
Can I run a large PDF job from a network drive?
You can, but it will be much slower, because the working copy is read and written across the network. For a job already measured in minutes, that can turn it into hours. Use an internal drive.
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.