PDF internals research

Why PDF Stream Share Sets the Compression Ceiling

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.

By BeanNest Studio Reviewed September 20, 2026

What this guide helps you decide

How much of a PDF can compression change when stream bytes make up very different shares of the file?

This research explains and measures the structure that determines PDF compressibility using this repository's own four-file corpus. It does not claim a universal compression ratio, and it does not describe a specific commercial compressor's internals.

Try it on the anchor product: BeanNest Tools /pdf/.

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.

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.

First-party evidence and provenance

How we checked this

We generated four single-page PDFs with this repository's own writer, then parsed each file's raw byte structure with this repository'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.

Method: We generated four single-page PDFs with this repository's own writer, then parsed each file's raw byte structure with this repository's own analyzer. Both tools are dependency-free and deterministic, so the same commands reproduce the same numbers on any machine.
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 this repository owns.
Captured: September 20, 2026
Reviewed by: BeanNest Studio

Repository evidence artifacts:

tools/research-evidence/pdf/analysis-2026-09-20.json
tools/research-evidence/pdf/README.md