BASALT · JOURNAL
Page count and file size are almost unrelated
Two documents, both a thousand pages. One is 800 KB and the other is 400 MB. Both are entirely normal, and the difference decides how every tool will behave on them.
Where the weight is
A text page stores instructions: use this font, move here, draw this string. A page of dense text is a few kilobytes.
A scanned page stores a photograph. At 300 DPI in colour, several hundred kilobytes to a megabyte after compression.
The ratio is roughly a hundred to one, which swamps everything else. Page count tells you about reading time; file size tells you about machine time.
Which number predicts what
File size predicts memory pressure, opening time on applications that buffer, transfer time, and disk needs.
Page count predicts rendering work when scrolling, OCR duration, and review effort.
Marked pages, not either of the above, predicts redaction time, because unmarked pages are copied through untouched.
Why the confusion causes trouble
People plan document work from page counts because that is the number that appears in a production letter. A "modest" 800 page production that turns out to be 350 MB of colour scans is a different job from an 800 page text export, in every respect that involves a computer.
Ask for the size before estimating the time.
Mixed documents
Real productions are frequently both: native text exports for correspondence, scans for anything that existed on paper. Such a file has an average page size that describes nothing, and the redaction cost depends entirely on which kind of page each mark lands on.
If a job is taking far longer than a page count suggested, the marks are probably landing on the scanned portion.
A quick check
qpdf --show-npages file.pdf gives the page count without rendering. The Finder gives the size. Dividing one by the other gives an average page weight, and anything above a hundred kilobytes a page means you are looking at scans and should plan accordingly.
Frequently asked questions
Does page count determine PDF file size?
Barely. A text page is a few kilobytes and a scanned page at 300 DPI in colour is several hundred kilobytes to a megabyte, so two documents with identical page counts can differ by a factor of a hundred in size.
Which matters more for performance, pages or file size?
File size drives memory use, opening time and transfer time. Page count drives scrolling, OCR duration and review effort. Redaction time follows neither: it follows the number of marked pages.
How can I tell if a PDF is scanned without opening it?
Divide the file size by the page count. An average above roughly a hundred kilobytes per page indicates page images rather than text. qpdf --show-npages gives the count without rendering anything.
Why is my redaction slower than the page count suggested?
Because the marks are probably landing on scanned pages rather than text ones. A scanned page costs around a second to redact against roughly a tenth of that for text, and mixed productions make averages misleading.
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.