Standards 6 min read 14 October 2026

PDF Linearization Explained: Fast Web View and Byte-Range Requests

Linearized PDFs are structured so the first page can display before the entire file downloads — essential for large documents served over the web. This guide explains how linearization works at the byte level, when to enable it, and how it interacts with PDF readers and CDN caching.

Open a PDF in a browser tab and notice whether the first page appears while the rest of the document still loads — or whether the browser shows a blank screen until the entire file has downloaded. That difference is linearization, also called Fast Web View in Adobe's terminology. A linearized PDF has its internal structure rearranged so that the data needed to render the first page appears at the very beginning of the file, allowing progressive rendering over HTTP. Linearization is one of the few PDF optimisations that requires no perceptible quality trade-off — it does not compress images more aggressively, remove metadata, or change visual output in any way. It reorganises existing data. Yet it remains underused, partly because it is not always obvious how to check whether a PDF is linearized, and partly because many PDF creation pipelines lose linearization on subsequent edits. This guide explains what linearization does at the file structure level, when it meaningfully improves load performance, how to create linearized PDFs with common tools, and how to verify the linearization state of an existing file.

What linearization does to a PDF file

A non-linearized PDF stores objects in roughly the order they were created — which has no relationship to the order in which they need to be rendered. The cross-reference table or cross-reference stream at the end of the file indexes all objects. To display any page, the browser must first download the entire file (to read the cross-reference at the end), then use the cross-reference to locate the objects needed for the requested page. A linearized PDF reorganises the file in a specific order defined by the PDF specification: 1. Linearization parameter dictionary — A special dictionary near the very beginning of the file that identifies the file as linearized and provides offsets to key structures. 2. First-page cross-reference table — An xref table covering only the objects needed to render the first page. This enables the browser to begin rendering immediately after downloading just the first portion of the file. 3. First-page objects — All objects required to render page 1: the page object, its content stream, fonts, images, and resource dictionary. These are placed contiguously so they can be streamed and rendered in a single HTTP request (with range requests). 4. Other objects — The remaining pages, their resources, and shared objects appear next. 5. Main cross-reference table/stream — The complete xref for all objects appears near the end (or beginning for some implementations), enabling full random access once the file is downloaded. 6. Hint tables — Optional but standard: hint tables at the beginning store offsets and sizes for all page objects, enabling byte-range requests to jump directly to any page without a full download.

HTTP byte-range requests and linearization

Linearization achieves its full benefit in combination with HTTP byte-range requests (Range: header). When a browser or PDF viewer requests a linearized PDF, the sequence is: 1. The viewer downloads the first portion of the file (typically a few kilobytes to tens of kilobytes) — enough to read the linearization dictionary and first-page xref. 2. The viewer parses the first-page xref, identifies the byte ranges of all first-page objects. 3. The viewer issues targeted HTTP Range: requests for those specific byte ranges. 4. Page 1 renders — often before the rest of the file has been fetched at all. 5. For subsequent pages, the viewer uses the hint tables to calculate the byte offset of any page and issues a targeted range request — without downloading pages it does not need. For large PDFs (reports, presentations, manuals) accessed over typical internet connections, this can reduce time-to-first-render from tens of seconds to under a second. For small PDFs (under ~100 KB), the overhead of the linearization structures sometimes makes the linearized version slightly larger, and the latency savings are negligible since the whole file downloads quickly anyway. PDF.js note — Mozilla's PDF.js (used in Firefox, and available as a web component) supports linearized PDF byte-range fetching when the server sends the Accept-Ranges: bytes response header and the PDF is linearized. Chrome's built-in PDF viewer also uses range requests for linearized PDFs.

Creating linearized PDFs

Adobe Acrobat Pro — File > Save As > PDF > and ensure "Optimized for Fast Web View" is checked. Alternatively, File > Save As Other > Optimized PDF > check "Enable Fast Web View". Note: using File > Save (rather than Save As) on a modified PDF may produce a non-linearized incremental update; Save As rebuilds the file and applies linearization. Ghostscript — Use the -dFastWebView=true flag: gs -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -dFastWebView=true -sOutputFile=output.pdf input.pdf qpdf — The qpdf command-line tool has a dedicated linearize option: qpdf --linearize input.pdf output.pdf qpdf is reliable, open-source, and available via most package managers (apt install qpdf, brew install qpdf). PDF libraries — Apache PDFBox supports linearization via its PDFMergerUtility with the linearize method. iText's commercial tier supports linearization. pdf-lib (JavaScript) does not currently support linearization output — the output is valid PDF but not linearized. Critical caveat: linearization is destroyed by editing — If you open a linearized PDF in a tool and save it with incremental updates, the incremental structure appended to the end of the file breaks linearization. The file must be fully rebuilt (saved with linearization) after any structural change. Verify linearization state after any PDF processing step in your pipeline.

Verifying linearization

qpdf — The most reliable command-line check: qpdf --check input.pdf reports whether the PDF is linearized and whether the linearization is valid (since a PDF can claim to be linearized but have an invalid hint table or misaligned offsets). Ghostscript — gs -dBATCH -dNOPAUSE -sDEVICE=nullpage -c "(input.pdf) (r) file runpdfbegin linearized? = quit" — outputs "true" or "false". Text inspection — Open the PDF in a text editor (or run strings input.pdf | head -20). A linearized PDF has a linearization parameter dictionary near the very beginning: look for /Linearized 1 in the first few hundred bytes. A non-linearized PDF will not have this. Adobe Acrobat Pro — File > Properties > Description tab — look for "Fast Web View: Yes" near the bottom of the dialog. Chrome DevTools — Load the PDF URL in Chrome, open DevTools > Network, click the PDF request, and examine the request log. A linearized PDF served with Accept-Ranges: bytes will show multiple small range requests rather than a single large download.

Frequently asked questions

Does linearization affect PDF file size?

Linearization has a small overhead — it adds a linearization parameter dictionary, a first-page cross-reference table, and optional hint tables. For most PDFs, this adds 1–5 KB. For large PDFs (tens of megabytes), this overhead is negligible. For very small PDFs (under 50 KB), linearization may increase the file size by a few percent with no meaningful performance benefit, since the whole file downloads in a single round-trip anyway. Linearization does not compress or decompress any existing content — it reorganises existing objects and adds metadata structures.

Is linearization the same as compression or optimisation?

No. Linearization is a structural reorganisation — it moves existing objects to new positions in the file for progressive rendering. Compression (downsampling images, applying FlateDecode to uncompressed streams, removing redundant objects) reduces the total file size. These are independent optimisations that complement each other. A well-prepared PDF for web delivery should be both compressed (to reduce total download size) and linearized (to enable first-page rendering before the full download completes). Tools like Acrobat Pro's PDF Optimizer and qpdf's --compress-streams flag can apply both. Ghostscript's -dPDFSETTINGS=/ebook or /screen preset applies compression; adding -dFastWebView=true adds linearization.

Does linearization work with HTTPS and CDNs?

Yes, with caveats. HTTP byte-range requests work over HTTPS. CDNs (Content Delivery Networks) generally support range requests for static assets — AWS CloudFront, Cloudflare, and most major CDNs pass through Range: headers and return 206 Partial Content responses. However, some CDN configurations disable range requests for small files or apply transformations that rebuild the file (stripping linearization). Verify by checking the response headers: the server must return Accept-Ranges: bytes and respond to Range: requests with 206. Vercel's static hosting, which is used for this site, supports range requests for static files, making linearized PDFs viable for any PDFs served directly from the deployment.

Try it yourself

Everything in this article can be done directly in the free PDFTheGuide editor — no account required.

Compress PDF Edit PDF Open editor