What Is a Linearized PDF? The Technical Background of Fast Web View

Of two PDFs the same size, one opens instantly in the browser while the other shows a blank page until it has fully downloaded. The difference isn't in the file's content — it's in how the objects are ordered inside the file. This article explains PDF's reading mechanism, how linearization inverts that mechanism, and what hint tables are for.

Why PDF is read from the end

At the end of a PDF file you find these three things:

startxref
1247893
%%EOF

The startxref line says at which byte of the file the cross-reference table begins. The first thing a viewer does when opening a PDF is read the last few hundred bytes of the file and find that number.

Then it goes to that byte and reads the xref table. That table lists every object's number in the file and which byte it starts at. After the table comes a trailer dictionary, which names the catalog object's number.

Now the viewer can find the catalog. From the catalog it reaches the page tree, from the page tree the first page object, and from there the content stream and the resources it uses. Those resources can live anywhere in the file — the first page's font might be in the middle of the file and its image near the end.

There's a reason for this design: incremental updates. When a change is made to a PDF, instead of rewriting the whole file, the changes are appended and a new xref table is written. The new table points to the old one, saying "for anything unchanged, look there." The file grows but the operation is fast, and the older version stays in the file. Digital signatures work on the same basis.

The cost: you have to see the end of the file before you can read any part of it.

Why that's a problem over a network

On a local disk, jumping to the end of a file is essentially free. Over a network it's a different story.

When a browser requests a PDF from a server, the server starts sending the file from the beginning. The information the viewer needs is at the very end. So in practice, to draw the first page, the whole file has to download.

A 50 MB catalog takes about 40 seconds on a 10 Mbps connection. The user stares at a blank page for those 40 seconds. Most users don't wait.

Linearization inverts the ordering

The structure of a linearized PDF looks like this:

| Position | Content | |---|---| | Start of file | The linearization parameter dictionary (/Linearized) | | Right after | The first page's xref table and trailer | | Then | All of the first page's objects (content, fonts, images) | | Then | The hint tables | | Then | The other pages' objects, in page order | | End of file | The main xref table (for compatibility) |

The parameter dictionary at the very start says: this file is linearized, its total length is this, the first page's objects run to this byte, the hint tables start here.

Thanks to that, the moment the viewer has the file's first few hundred kilobytes it has everything it needs to draw the first page. The user starts reading page one while the download continues.

Hint tables: the structure that makes page jumping possible

Linearization's second and perhaps more valuable benefit is being able to jump straight to a requested page.

Hint tables are the structure that makes this possible. There are two:

The Page Offset Hint Table: for each page, it lists which byte that page's objects start at and how many bytes they run. When the user jumps to page 147, the viewer consults this table, learns "page 147 is between bytes 8,234,100 and 8,291,000," and requests only that range from the server.

The Shared Object Hint Table: it lists resources used by multiple pages — embedded fonts used throughout the document, a logo repeated on every page. If page 147 needs some of those, the viewer learns their byte ranges from here too.

The result: in a 500-page, 80 MB file, seeing page 147 takes only a few hundred kilobytes of download.

Byte-range: the server-side condition

The mechanism above depends on the browser being able to tell the server "give me bytes 8,234,100 through 8,291,000 of this file." In HTTP that's done with the Range header, and the server has to answer with 206 Partial Content.

Nearly every modern web server supports this for static files and it's usually on by default. But it doesn't work in these cases:

• If the file is generated dynamically (an application server building the PDF on the fly), byte-range is usually not supported.
• If the response is gzip-compressed, byte ranges become meaningless. Since PDFs are already internally compressed, applying gzip on the server is both unnecessary and the cause of this problem.
• Some CDN or proxy configurations may not pass range requests through.

If any of these conditions applies, the browser has to download the whole file even though linearization was done, and the benefit disappears.

What linearization doesn't change

This point needs to be clear, because there's a common misunderstanding:

File size. Linearization discards no content and re-encodes no images. Because hint tables are added, the file typically grows by 1-2%. If you want it smaller, you need compression.

Image quality. Not a single pixel changes.

Text, fonts, layout. None of them are affected.

Local open speed. If the file is already on disk, the ordering doesn't matter; a linearized file doesn't open faster locally.

When linearization gets broken

A linearized file can lose this property when it's operated on:

Any operation that does an incremental update breaks it. Adding an annotation, filling in a form field, applying a digital signature — most of these append changes to the end of the file. The file is still valid, but now the viewer has to look at the end to learn the current state; linearization's promise no longer holds.

Operations that do a full rewrite also break it: compression, adding or deleting pages, merging, splitting. These produce the file from scratch and the special linearized ordering isn't preserved.

The practical consequence: linearization should be the last step of the workflow. Compress, edit, sign, do whatever you need — then linearize at the very end and publish.

How to verify

The simplest way to tell whether a file is linearized is to look at its first bytes. In a linearized PDF the first object looks like this:

1 0 obj
<< /Linearized 1 /L 1247893 /O 6 /E 45231 /N 120 /T 1247100 >>
endobj

The /Linearized 1 key is direct proof. /N gives the total page count, /L the file length, /O the object number of the first page.

To test under real conditions, upload the file to a server and open it in your browser's developer tools with slow connection simulation. With a linearized file the first page appears before the download completes.

In summary

PDF puts the cross-reference table at the end of the file to make incremental updates possible; over a network that means waiting for the whole file. Linearization inverts the ordering: everything for the first page comes to the front, followed by hint tables saying where each page lives. That way the first page appears immediately and you can jump straight to any page — but only if the server supports byte-range requests. The operation doesn't reduce file size, doesn't change quality, and doesn't speed up local opening. It's only meaningful for large files published on the web, and because it gets broken by any other operation on the file, it should be applied as the last step.