What is a linearized PDF?

Why a normal PDF has to be read backwards

A PDF's index lives at the end. The cross-reference table — the map of where every object sits in the file — is written last, and a reader has to find it before it can locate anything else. That is why opening a PDF means seeking to the end of the file first.

For a file on your disk that costs nothing. For a 40MB file arriving over a network it means the reader can display nothing at all until the whole thing has downloaded, because until the index arrives it does not know where page one is.

Linearization rearranges the file so this is not necessary. The objects needed for the first page are moved to the front, along with a small hint table telling the reader where everything else will be. A reader that understands it can render page one from the first chunk of bytes and fetch later pages on demand.

What it changes, and what it doesn't

The distinction people miss: linearizing changes the order of the file's contents, not the contents themselves.

• The pages, text, images and fonts are identical. Nothing is recompressed, nothing is lost, nothing looks different.
• The file size is essentially unchanged — very slightly larger, because the hint tables are extra data.
• It requires a server that supports byte-range requests, so the reader can ask for part of a file. Every normal web server does.
• It only helps when the file is being streamed. Opening a local file, or one already fully downloaded, gains nothing.

Why it matters less than it used to

Linearization was designed in an era of dial-up and browser plugins, when a 5MB PDF took minutes and Fast Web View was the difference between usable and not.

Two things eroded that. Connections got fast enough that most documents arrive in a moment regardless of layout. And browsers replaced plugin-based viewing with their own PDF engines, most of which download the whole file before rendering anyway — so the optimisation the file offers goes unused.

It still earns its place in specific situations: large documents served over the web, mobile users on poor connections, and document management systems that serve individual pages from long files. For a ten-page invoice emailed as an attachment, it is irrelevant.

The catch worth knowing

Linearization is fragile in a way that surprises people. Any tool that modifies a PDF and saves it will almost certainly write out a normal, non-linearized file — because rewriting the document means rebuilding the cross-reference table, and preserving the linearized layout is extra work most libraries do not do.

So a file can be linearized when published and quietly stop being so after someone rotates a page, fills in a form, or runs it through a compressor. Nothing warns you. If Fast Web View matters for a document, linearize as the last step before publishing, not somewhere in the middle of the pipeline.

This is also why checking a file's properties can be confusing: a document that was definitely linearized once reports Fast Web View as No, because it has been through an editor since.

Do you need it?

Ask two questions. Is the file large — tens of megabytes rather than a few? And will people open it directly from a link rather than downloading it first?

Two yeses and linearization is worth the final step. Otherwise it is a property that costs nothing to have and buys nothing in practice, which is a fair description of most optional PDF features.

Frequently asked questions