What Is a Linearized PDF? Fast Web View Explained Simply

A linearized (or linearised) PDF is a file whose internal parts are arranged so a viewer can show the first page before the whole file has downloaded, then fetch other pages on request. Many programs call this Fast Web View. The pages look exactly the same; only the order of data inside the file changes, plus some navigation tables.

Linearisation is defined in Annex F of ISO 32000-1, the PDF 1.7 standard, and it has been an optional feature since PDF 1.2. This article explains what it changes inside the file, when it helps, why regulators ask for it in electronic submissions, and the one ordering mistake that quietly undoes it.

How an ordinary PDF is read

A PDF is a collection of numbered objects (pages, fonts, images, text streams) plus a cross-reference table that records where each object starts. In an ordinary PDF that table and the file trailer sit at the end. ISO 32000-1 section 7.5.5 says it directly: conforming readers should read a PDF file from its end.

That works well for a file on your own disk. Over a network it is awkward: before the viewer can draw page 1, it needs the end of the file to find out where page 1 is. On a slow connection, or with a large document, you wait for most of the download before anything appears.

What linearisation changes

Annex F sets out the goals plainly. When a document is opened, the first page should display as quickly as possible; when you ask for another page, that page should display as quickly as possible; and the total number of pages should have little or no effect on how fast any particular page appears. To achieve this, a linearised file adds two things:

• Ordering rules. The objects are split into two groups. The first holds the document catalogue, other document-level objects and everything needed for the first page. The second holds all remaining pages and shared objects (ISO 32000-1, F.3.1).
• Hint tables. Extra data structures, stored in a hint stream, that tell the viewer where each later page's objects are, so it can request just those bytes.

The file also starts with a linearisation parameter dictionary, which must sit entirely within the first 1,024 bytes of the file. That limit exists so a viewer only has to read the very start of a file to decide whether it is linearised.

The design relies on a feature of HTTP described in Annex F.2: a viewer can ask a web server for specific byte ranges of a file rather than the whole thing. If the server or the viewer does not support byte-range requests, the viewer simply downloads the file in order, and the early pages still tend to arrive first.

Is a linearised PDF still a normal PDF?

Yes. Annex F states that a reader that does not support linearisation can still process a linearised file, only less efficiently. Text, fonts, images, bookmarks, links and form fields are all untouched. You cannot tell a linearised file from an ordinary one by looking at the pages.

Two things it is not:

• It is not compression. Linearisation reorders objects and adds hint tables. Any change in size is a side effect of the file being rewritten, not the purpose. If you need a smaller file, compress first, then linearise.
• It is not PDF/A. PDF/A is an ISO standard for long-term preservation with its own rules on fonts, colour and content. A file can be linearised, PDF/A, both or neither.

The ordering trap: edits after linearising

Annex F contains a sentence that matters more than any other in practice: an incremental update is still permitted, but the resulting PDF is no longer linearised and shall be treated as an ordinary PDF. Linearising it again may require reprocessing the entire file.

An incremental update is the way many programs save small changes: they append the changes to the end of the file instead of rewriting it (ISO 32000-1, section 7.5.6). So if you linearise a document and then add a comment, fill a field, or save it again in an editor that appends changes, the file stops being linearised even though nothing looks different.

Digital signatures add a twist. ISO 32000-1 notes that each signature results in an incremental save, so signing a linearised file ends its linearisation. The reverse is worse: linearising a signed file rewrites every byte, and a signature only stays valid if the signed bytes are unchanged, so the signature will fail. If a document needs both, linearise the final unsigned version, sign it last, and accept that the signed file is no longer strictly linearised. If your agency or publishing system has a rule for this case, follow it.

Why regulators ask for fast web view

For anyone preparing an eCTD, fast web view is not a nicety. All three key documents ask for it:

• The FDA's Portable Document Format (PDF) Specifications (version 4.1) asks for files to be created using the "Optimize the PDF for fast web view" option, to reduce file sizes and file opening times.
• The EMA's harmonised eCTD guidance (version 6.0.1, section 2.9.3) asks applicants to use 'Fast Web View' where possible to ensure optimum performance of the review system.
• Appendix 7 of the ICH eCTD Specification v3.2.2 says to optimise PDF files for fast web view, alongside the 100 megabyte file size limit.

The EMA wording gives the reason: reviewers open documents in a review system, and a long report that opens at page 1 straight away is easier to work with. The wider checklist is in our guide on preparing PDFs for regulatory submissions.

How to check whether a PDF is linearised

1. Look at the document properties. View Metadata shows a "Linearized (Fast Web View)" row, using the flag reported by the PDF.js library when it opens the file.
2. Run a structural check. The open-source qpdf command-line tool has a --check-linearization mode that reads the linearisation dictionary and hint streams and checks that object ordering, parameters and hint stream contents are correct. This is stricter than a yes or no flag.
3. Test it the way a reviewer would. Put the file on an internal web server and open it in a browser on a slow connection. A linearised file shows page 1 almost at once.

If a file you linearised now shows as not linearised, check whether anything saved it again afterwards, because an incremental update ends linearisation. Linearise it again as the final step.

How to linearise a PDF

PDF creation software often offers this as a save option; the FDA specification calls it "Optimize the PDF for fast web view". If yours does not, or you need to fix an existing file:

1. Finish every other change first: bookmarks, links, page numbers, compression, metadata.
2. Open Linearize PDF and add one file or several. The tool runs qpdf, compiled to WebAssembly, in your browser with the --linearize option, so files are not uploaded. It writes a new file named yourfile_linearized.pdf, or a ZIP if you add several.
3. Compare the original and new sizes the tool reports. Do not expect a large saving: linearisation is about order, not size.
4. Open the result and confirm the pages, bookmarks and links still work, then check the flag in View Metadata.
5. Do not edit or re-save the file afterwards. If you must, linearise again.

One limitation to know: the tool shows an option to use object streams, but at the time of writing its worker passes only the plain --linearize option to qpdf, so that checkbox does not change the output.

When linearisation is not worth the effort

If a PDF lives on a shared drive, is emailed as an attachment or is only a few pages long, the viewer has the whole file anyway and the ordering makes little difference. Annex F was written for slow, request-and-response networks; it notes that a linearised file is optimised for read-only documents that are generated once and read many times. Large reports, manuals and submission documents published to a web server or review system are where it pays off.

This article is general information about the PDF format, not regulatory advice. For submissions, follow the current version of each agency's specification and your publishing team's procedures.