Sample PDFs

Purpose

Each PDF contains a recognizable rainbow-grid label image (top half), a unique high-entropy noise image (bottom half, forces real file size), and a per-page "Page N" header. Sizes were chosen to straddle the 2 GB and 4 GB byte boundaries (signed/unsigned 32-bit) and to test viewers' ability to stream linearized PDFs across them.

Quick answer

The PDF spec does not allow it. Linearized PDFs must use classic cross-reference tables, whose byte offsets are fixed at 10 decimal digits. That caps the addressable file size at 10¹⁰ bytes — about 9.31 GiB. Files larger than that cannot be cleanly linearized using the standard.

The longer version

Linearization (also called "Fast Web View") is defined in PDF 1.4 / Annex F of the ISO 32000 spec. It rearranges the document so the first page and its dependencies appear at the start of the file, and adds a hint table that lets a viewer render page 1 before the rest of the file has streamed. Without it, a viewer must download the entire PDF before it can render anything — the cross-reference table sits at the end of the file.

Linearization predates cross-reference streams (added in PDF 1.5), which encode object offsets in raw binary and support arbitrary file sizes. The two formats are mutually exclusive: per the Foxit PDF SDK header documentation for e_SaveFlagLinearized, "this should be used alone and cannot be used with other saving flags except e_SaveFlagNoUpdatingMetadataDateTime" — including the xref-stream flag. A linearized PDF must use the older classic xref table format, whose entries look like 0000123456 00000 n; that fixed 10-digit offset field tops out at 9,999,999,999 bytes.

How we tested the ceiling

We built a small custom binary, foxit_linearize.exe, against the Foxit PDF SDK Core (Windows C++) on our GPU box. It calls PDFDoc::SaveAs(output, e_SaveFlagLinearized) — the same code path the desktop product uses for "Save As Optimized for Fast Web View."

For each input we record the JSON returned by the wrapper, including IsLinearized() on the freshly-written output file. The behaviour we found is more conservative than the spec ceiling alone would predict:

• 1 / 3 / 5 GB: Foxit linearizes cleanly. IsLinearized() == true. Output sizes match input within a few KB. The variants in the table above were produced by Foxit.
• 9 GB: Foxit's SaveAs returns success and writes an output file, but reopening returns IsLinearized() == false. Foxit silently degrades to a non-linearized save even though the file is comfortably under the 10¹⁰-byte spec ceiling. We fell back to qpdf --linearize for this variant, which produces a clean linearized file at this size.
• 10 GB: same Foxit fallback. qpdf --linearize instead writes a malformed file with truncated offsets that most viewers reject. Both tools confirm the spec's hard ceiling; we don't ship a 10 GB linearized variant.

So Foxit's empirical threshold sits somewhere between 5 GB and 9 GB — not at 10 GB. The probable cause is an internal sanity check or 32-bit-signed offset usage in Foxit's hint-table generator, but we haven't binary-searched it. Net result: Foxit's behaviour is safer than qpdf's (no malformed output ever), but its useful linearization range is narrower.

What this test set covers

• 1 GB: baseline, well under any boundary.
• 3 GB: across the 2 GB (signed 32-bit) boundary — tests viewers that store offsets in int32_t.
• 5 GB: across the 4 GB (unsigned 32-bit) boundary — tests viewers that store offsets in uint32_t.
• 9 GB: largest cleanly-linearizable file (just under the 10¹⁰-byte ceiling).
• 10 GB: non-linearized only — uses cross-reference streams to remain valid past 10 GB.

Linearize when…

• The PDF is served over the web to a viewer that supports HTTP Range requests — Foxit PDF SDK for Web, PDF.js, the Acrobat browser plugin, most mobile readers. First-page render time goes from "wait for the whole download" to "a couple of round trips."
• Users typically open the file, scan a few pages, and bounce. Reports, datasheets, manuals, papers, brochures.
• The file is large (50 MB+) but well under 5 GB — the sweet spot for the streaming benefit before Foxit's silent fallback kicks in.
• You're behind a CDN. Range-request responses cache cleanly, so cold-cache page-1 latency stays low.
• You control the production pipeline and can run a one-time pass at publish time. Linearization is a few-percent size overhead and seconds-to-minutes of CPU; tiny next to the user-experience win.

Skip it when…

• The file will always be downloaded in full. Archival, batch processing, ETL, anything that immediately hands the bytes to another tool. Linearization buys nothing and adds size.
• The file gets edited. Every save invalidates the hint table; you'd need to re-linearize on each write. Editorial pipelines should leave files non-linearized until the final publish.
• The file is over ~5 GB. Foxit's own SDK silently degrades to non-linearized save above ~5 GiB (we measured this on the page above). Above ~9.3 GB nothing can produce a spec-valid linearized file at all — classic xref tables run out of digits.
• You need PDF 1.5+ features that require cross-reference streams. Linearization and xref streams are mutually exclusive in the Foxit C++ SDK (and mostly elsewhere). If you've added a 5 GiB embedded video or a million-object form, xref streams win.
• Serving only over fast LAN or to a desktop reader. Acrobat, Foxit Reader, macOS Preview all open multi-GB non-linearized PDFs without complaint. Linearization's streaming benefit is single-digit milliseconds when latency is already that low.
• You're targeting PDF/A-1 or another archival profile. Some forbid linearization entirely.

The short version

Linearization is a deployment-time optimization for one specific scenario: web-embedded viewers loading large documents over the public internet. For everything else — archives, edit pipelines, fast networks, the increasingly common multi-GB technical PDFs — the spec ceiling and edit fragility outweigh the streaming benefit. Treat it as a publish-step toggle, not a default. And if your file is already over 5 GB, don't bother trying.

Visual verification

Every page of every file shows its target size in the rainbow label (e.g. "1 GB", "10 GB") plus a "Page N" header. If you can read those, the viewer is rendering content streams correctly. The bottom-half noise image is unique per page so viewer-side image deduplication never short-circuits the test.