PDF internals research
What a Byte-Level PDF Analyzer Cannot Tell You
If the analyzer reports object counts, stream shares, and inflation ratios, what is it still not able to say about a PDF?
A measurement tool earns trust by stating where it stops. The research PDF analyzer behind these guides reports byte structure, and it is deliberately narrow. It does not render, it does not decrypt, it does not validate fonts, and it does not evaluate readability. Each of those omissions bounds which claims BeanNest is entitled to make, so we list them explicitly rather than leaving a reader to discover them.
Reviewed 2026-09-20 by BeanNest Studio
It does not render pages
The analyzer reads byte structure and never draws a page. It can report objects and streams, but it cannot say whether text overlaps, a glyph is visible, or a page looks correct. Visual-fidelity claims therefore sit outside this evidence.
It does not decrypt content
The analyzer can classify a Crypt filter name, but it has no key exchange or decryption path. It therefore cannot turn encrypted stream bytes into plaintext content or use those bytes to make a decompressed-content claim.
It does not inspect font subsets
The analyzer records font objects and whether an embedded font reference is present. It does not enumerate the glyphs carried by a subset or validate text extraction. Font-subset and extraction-quality claims are intentionally excluded.
It does not validate PDF conformance
No code in this analyzer certifies PDF/A, PDF/UA, accessibility conformance, or another profile. Structural parsing and standards conformance answer different questions, so a successful byte analysis is not a conformance result.
The measured corpus is deliberately small
The published PDF measurements come from four generated single-page files. The analysis artifact contains no images, embedded fonts, encryption, forms, annotations, or multi-page cases. Ratios measured on those files are evidence for those fixtures, not predictions for arbitrary PDFs.
What the analyzer reports directly
For the current corpus it reports the PDF version, object and stream counts, total stream bytes and share, Flate and JPEG byte totals, font records, image records, filter kinds, and a verified Flate inflation sample when available. Those fields come from byte inspection or an attempted decompression rather than from visual inference.
Filter recognition is broader than the measured corpus
The analyzer code recognises filter names including DCTDecode, JPXDecode, CCITTFaxDecode, JBIG2Decode, FlateDecode, and Crypt. The current analysis artifact nevertheless reports imageCount 0 for all four fixtures, so this corpus does not provide a measured photo-heavy or encrypted-file result.
Reading one number without overreading it
Take the stream share of 30.5 percent reported for text-40-flate.pdf. It means 250 of the file's 821 bytes sit inside stream data. It does not say whether the page looks right, whether the text can be selected, or whether a validator would accept the file. Every figure the analyzer prints answers a byte-accounting question, and a size tool should be judged the same way: look at the before and after sizes it shows, then open the result and check the pages yourself.
Questions it can answer and questions it cannot
It can answer how many objects a file holds, how many bytes sit in streams, which filter names appear, and whether a Flate stream really inflates. It cannot answer whether a page is legible, whether a scan is still sharp after recompression, whether a font will extract correctly, whether the file is accessible, or whether it is safe to open. Treating the first list as if it covered the second is the most common way a size claim turns into a quality claim.
Broader claims require broader fixtures
A future image, encryption, multi-page, or rendering claim needs a fixture that actually exercises that capability and a check that measures the relevant outcome. Until such evidence exists, the honest boundary is to keep those cases listed as unmeasured rather than infer them from nearby structural fields.
Scope of this guide
This research documents the boundaries of the BeanNest research PDF analyzer. It does not claim the analyzer is unsuitable for its stated purpose, and it does not describe other PDF tooling.
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 enumerated the analyzer's actual capabilities against a rendering, decrypting, font-subsetting, and conformance-checking baseline, and recorded each capability the analyzer does not have.
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 whenever analyzer capability changes, because a new capability invalidates the corresponding limitation.
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
- rendering, visual fidelity, or layout claims
- text-extraction quality claims
- conformance certification of any kind
- generalisation of corpus ratios to arbitrary PDFs