Open a 400-page PDF from a slow server and one of two things happens. Either the first page appears in a second and the rest streams in behind it, or you stare at a spinner until the whole file has arrived. The difference is linearization, and it has nothing to do with how big the file is.
What a normal PDF looks like from the outside in
A PDF is a collection of numbered objects — pages, fonts, images, content streams — followed by a cross-reference table that says where each object starts, and a trailer pointing at that table. The critical detail is that the cross-reference table is at the end of the file.
So a reader opening a PDF has to seek to the end first, read the table, and only then jump back to find the objects it needs. Over a local disk this is free. Over HTTP without range requests it means downloading the entire file before rendering anything, no matter which page you wanted.
That is why a big PDF on a slow connection shows nothing at all for a long time and then shows everything at once.
What linearization changes
A linearized PDF — Adobe's marketing name is Fast Web View — is the same document with its bytes rearranged so a reader can display page one after fetching only the beginning of the file. Four structural changes make that work.
A linearization parameter dictionary is the first object in the file. It carries /Linearized 1 plus the numbers a reader needs to plan its fetches: /L the total file length, /O the object number of the first page, /E the offset where the first page's data ends, /N the page count, /T the offset of the main cross-reference table, and /H the location and length of the hint stream.
A first-page cross-reference table sits near the top, covering just the objects needed for page one, with a /Prev pointer to the main table at the end. The reader gets a working index from the first few kilobytes.
Everything page one needs is moved to the front, contiguously — its content stream, its fonts, its images, its resources.
Hint tables are added. These are bit-packed tables describing where every other page's objects live and which objects are shared between pages, so the reader can request exactly the byte range for page 137 without downloading pages 2 through 136.
What linearization is not
It is not compression. A linearized file is the same size as the original, occasionally a little larger because of the hint tables. If your goal is a smaller file, linearization is the wrong tool — you want image downsampling, which is what Compress PDF does.
It does not make the file open faster locally. Once the bytes are on your disk, the cross-reference table at the end costs nothing to seek to. Linearization is purely a network-delivery optimisation.
It does not survive editing. Any tool that appends an incremental update — adding an annotation, filling a form, signing — writes new objects and a new cross-reference table at the end, which breaks the linearized layout. Files must be linearized as the last step before publishing, not somewhere in the middle of a pipeline.
It only helps when the server supports byte-range requests. The whole point is fetching parts of the file. If the server does not send Accept-Ranges: bytes, or the PDF sits behind a proxy that buffers whole responses, a linearized file streams no better than a normal one.
How to check whether a PDF is linearized
The most reliable check is qpdf, which validates the structure rather than just looking for the keyword:
qpdf --check document.pdfLook for the line File is linearized. qpdf also reports when the linearization data is present but inconsistent, which is a genuinely useful distinction — some tools write the dictionary without maintaining valid hint tables, producing a file that claims Fast Web View and does not deliver it.
A quick, cruder check: the linearization dictionary must be the first object, so it appears in the opening bytes.
head -c 200 document.pdf | strings | grep -i linearizedIn Acrobat, File → Properties shows Fast Web View: Yes/No.
How to linearize a PDF
Two reliable commands, both local, both free.
qpdf is the reference implementation and the one to prefer:
qpdf --linearize input.pdf output.pdfMuPDF does it as part of cleaning:
mutool clean -l input.pdf output.pdfGhostscript has a -dFastWebView=true option for pdfwrite, but it rewrites the entire document in the process, which changes far more than the byte layout. Use qpdf when you want to change only the ordering.
Why PDFBase does not offer a linearize tool
It did, once, and the tool was removed rather than fixed, because what it produced was not a linearized file. It reordered some objects and left the cross-reference structure alone — which is to say it produced an ordinary PDF with extra steps, while the page told you it had optimised the file for the web.
Producing a genuinely linearized PDF means renumbering every object so the first page's objects are contiguous, emitting a valid parameter dictionary with self-referential offsets, generating correct bit-packed page-offset and shared-object hint tables, and writing two cross-reference tables that agree with each other. That is a real piece of engineering, and a half-implementation is worse than nothing, because a file that claims Fast Web View and does not deliver it will not be re-checked by whoever relies on it.
So the honest answer is the one above: run qpdf --linearize. It is two seconds of work, it is correct, and it is verifiable with qpdf --check immediately afterwards.
When it is actually worth doing
Linearize when all of these are true:
- The PDF is served over HTTP and read in a browser rather than downloaded first.
- It is large enough for the wait to be noticeable — realistically 2 MB and up.
- It has enough pages that a reader might jump around instead of reading linearly.
- Your server supports byte-range requests.
Skip it for anything under a megabyte, for files people download and open locally, for email attachments, and for any file that will be edited afterwards. For a two-page invoice it changes nothing measurable.
And if the real complaint is "this PDF takes forever to load", check the file size first. A 40 MB scan is slow because it is 40 MB, and reordering its bytes will not help. That is a job for Compress PDF, or — for scanned paperwork with no colour worth keeping — 1-bit conversion, which routinely takes a scanned page from several hundred kilobytes to under a hundred.