PDF internals research
Why PDF Stream Share Sets the Compression Ceiling
How much of a PDF can compression change when stream bytes make up very different shares of the file?
A PDF contains stream bytes and structural bytes, and compression can only change the bytes a compressor actually rewrites. Our four generated fixtures isolate that split: one raw text file, two compressed text files of different sizes, and one compressed file padded with forty extra objects. The measured stream shares show why the available ceiling differs before any broader prediction is made.
Reviewed 2026-09-20 by BeanNest Studio
The four fixtures isolate different variables
The corpus contains text-40-raw.pdf, text-40-flate.pdf, text-200-flate.pdf, and text-40-flate-padding.pdf. They let the analysis compare raw versus Deflate storage, more text under the same compression method, and extra structural objects while the compressed forty-line content stream stays the same.
The raw and compressed forty-line pair measures one reduction
The raw forty-line file is 5135 bytes with 4583 stream bytes, a stream share of 89.3 percent. Its compressed counterpart is 821 bytes with a 250-byte Flate stream. That paired fixture is about 84 percent smaller, and the measured inflation ratio for the compressed stream is 18.328x.
Padding changes the share without changing the content stream
The padded fixture is 5930 bytes and still contains the same 250-byte compressed content stream as the 821-byte forty-line compressed file. Its stream share falls to 4.2 percent because forty additional objects increase structure while the page content stream remains unchanged.
More text produces a different measured shape
The two-hundred-line compressed fixture is 1287 bytes with a 715-byte stream, so streams account for 55.6 percent of the file. That stream inflates to 22923 bytes, a measured ratio of 32.06x. These numbers describe this deliberately repetitive text fixture, not a typical document.
Stream share is a structural clue, not a promised saving
A high stream share means more of the file sits in bytes that may be candidates for compression, while a low share means structure already occupies most of the file. The share alone does not guarantee a percentage reduction because compressibility also depends on what those stream bytes contain.
The current corpus does not measure image-heavy PDFs
All four analysis records report imageCount 0 and jpegStreamCount 0. The analyzer can classify image filters, but this corpus supplies no measured before-and-after compression result for photographs, scans, embedded fonts, encrypted files, or multi-page documents.
The ceiling as arithmetic
Subtract the stream bytes from the file size to get the bytes outside streams: 552 for text-40-raw.pdf, 571 for text-40-flate.pdf, 572 for text-200-flate.pdf and 5680 for the padded file. A change that only rewrites streams cannot remove those bytes. If a recompressor shrank the stream in text-40-flate.pdf to nothing, the file would still be at least 571 bytes, so the most such a change could save is the 250 stream bytes, 30.5 percent, which is exactly the stream share.
Small differences outside the streams
The compressed fixtures carry 19 and 20 more bytes outside the stream than the raw one (571 and 572 against 552). The analysis does not itemise those bytes, and next to the 5135-byte raw file or the 821-byte compressed file they are small. They are a reminder that the non-stream part is not a fixed constant, so the ceiling should be computed per file.
Using the idea on a real file
A PDF made mostly of photographs or scans will have a very different shape from these text fixtures, and its stream bytes may already be compressed. When you use Compress PDF, treat the before and after sizes it shows as the result for that file, and use the stream-share idea only to understand why one file shrinks a lot and another barely moves.
Use the corpus to reason about mechanism, not to copy a percentage
For an unfamiliar file, stream share can identify whether content or structure dominates the byte total. Any claimed reduction still needs a measurement on that file or a representative corpus. The 84 percent figure belongs to the raw/compressed forty-line pair and should stay attached to that fixture.
Scope of this guide
This research explains and measures the structure that determines PDF compressibility using BeanNest's own four-file corpus. It does not claim a universal compression ratio, and it does not describe a specific commercial compressor's internals.
Method and evidence
We generated four single-page PDFs with BeanNest's own writer, then parsed each file's raw byte structure with BeanNest's own analyzer. Both tools are dependency-free and deterministic, so the same commands reproduce the same numbers on any machine. For this guide we compared the four corpus files against each other on total bytes, flate bytes, stream share, and inflation ratio, to isolate which structural property decides how much a file can shrink.
Environment: Node.js on a desktop workstation. No PDF library, no network access, and no third-party file was used. The corpus is produced from text BeanNest owns.
Captured: 2026-09-20. Re-review trigger: Re-review when the PDF corpus, the analyzer, or the corpus manifest changes, because the published numbers are derived from those exact files.
Evidence files: kept in BeanNest's source repository, not published on this site.
docs/research-evidence/pdf/analysis-2026-09-20.jsondocs/research-evidence/pdf/README.md
What this guide does not claim
- a universal per-file compression ratio or a guaranteed percentage
- comparisons against a named commercial PDF compressor's internals
- claims about compression of files we cannot regenerate
- performance or speed claims about any specific tool