How to optimise a pdf for web browser display
- Step 1Open the optimiser and drop your PDF — Load the document into PDF Linearize (Fast Web View). One file at a time — it does not accept multiple inputs.
- Step 2Decide if you need to compress first — Linearization will not shrink the file. If a brochure is several megabytes, run lossless compression (keeps text) or aggressive compression (scans) first, then come back here last.
- Step 3Leave the password field blank unless the PDF is encrypted — Web-served documents are usually unencrypted. The field placeholder reads 'Leave blank for unencrypted PDFs' — that's the normal path.
- Step 4Leave Force off for the normal case — If the file already has the hint stream the tool returns it unchanged. Only tick 'Re-linearize even if the input is already linearized' when you want a forced rebuild after editing the file elsewhere.
- Step 5Run and download the optimised PDF — qpdf rebuilds the cross-reference table and writes the first-page hint dictionary at the front, in WebAssembly locally. Save the output — it opens identically in every reader.
- Step 6Deploy and confirm Fast Web View — Upload to your server, then open the live URL in Acrobat → File → Properties → Description and confirm 'Fast Web View: Yes'. Ensure the server answers byte-range requests (
Accept-Ranges: bytes).
What this tool does and does not do
'Web optimise' is used loosely elsewhere. Here it means one specific thing — linearization. Use a sibling tool for the rest.
| Web-optimisation task | This tool? | Correct tool |
|---|---|---|
| Render page 1 before the file finishes loading in a browser | Yes | PDF Linearize |
| Reduce download size (text PDF) | No | Lossless compress |
| Reduce download size (scan / image-heavy) | No | Aggressive compress |
| Remove author / software metadata before publishing | No | Metadata scrubber |
| Make an old reader open the file | No | Version converter |
How browser viewers handle a linearized PDF
All major browser viewers render linearized PDFs progressively when the server supports byte-range requests. They all open non-linearized files too — just without the early first-page paint.
| Browser viewer | Renders progressively from linearized file? | Requires |
|---|---|---|
| Chrome / Edge (Chromium PDFium) | Yes | Server Accept-Ranges: bytes |
| Safari (PDFKit) | Yes | Server Accept-Ranges: bytes |
| Firefox (pdf.js) | Yes — streams page-by-page | Server Accept-Ranges: bytes |
| Acrobat / Reader embedded | Yes — 'Fast Web View' | Server Accept-Ranges: bytes |
Input limits by tier (PDF family)
These caps gate the file you can load; processing then happens in your browser.
| Tier | Max file size | Max pages |
|---|---|---|
| Free | 2 MB | 50 |
| Pro | 50 MB | 500 |
| Pro Media | 500 MB | 2,000 |
| Developer | 2 GB | 10,000 |
| Enterprise | unlimited | unlimited |
Cookbook
Real runs for web-served documents, focused on the browser-display outcome.
A long brochure that flashed blank in Chrome
A 9 MB product catalogue exported from InDesign showed a blank pane for a few seconds in Chrome's viewer on a 4G connection. Linearizing lets PDFium paint page 1 from the first chunk.
Options: password (blank), force off Before: Chrome downloads all 9 MB, then renders page 1 After: Chrome renders page 1 from first bytes, streams rest Note: size still ~9 MB — compress first to cut the rest
Compress, then optimise for display
The right two-step for a heavy web PDF. Shrink it first, then linearize the smaller file.
Step 1: pdf-compress-lossless → 9 MB → 6.1 MB (text kept) Step 2: pdf-linearize → 6.1 MB, Fast Web View: Yes Download is smaller AND page 1 paints early.
Firefox pdf.js page-by-page streaming
Firefox's pdf.js streams a linearized PDF page by page over byte-range requests. The reader scrolls through a 200-page report without the whole file being in memory at once.
Server: Accept-Ranges: bytes (Nginx default) File: report.pdf, linearized pdf.js requests byte ranges as the reader scrolls → first page visible in well under a second on broadband
Already-optimised file, redeploy is free
Your CI re-uploads the same PDF nightly. With Force off, the linearizer detects the existing hint stream and returns the file untouched.
Options: password (blank), force off inspectLinearization() finds /Linearized in head → alreadyLinearized: true → output == input
Encrypted client-portal PDF
A statement behind an open password, served in an authenticated web area. Supply the password so qpdf can round-trip it.
Options: password: 7Hd!2 , force off qpdf --password=7Hd!2 --linearize statement.pdf out.pdf → decrypt → linearize → re-encrypt, one pass → output stays encrypted, displays progressively once unlocked
Edge cases and what actually happens
Browser still renders slowly after linearizing
Server configProgressive display needs the server to answer Range: requests with Accept-Ranges: bytes. If a framework streams the PDF through a request handler rather than serving it as a static file, ranges may be disabled and the browser falls back to downloading the whole file. Verify with curl -I and serve the PDF as a static asset.
You wanted the page to load less data, not just sooner
By designLinearization changes *when* the first page appears, not *how much* is downloaded overall. The total bytes are roughly the same. To cut the download, compress first — lossless for text, aggressive for scans — then linearize.
Encrypted input without a password
Errorqpdf cannot open an encrypted file without credentials; it exits 2 and the tool reports 'qpdf could not process this PDF — it may be corrupted or use an unsupported encryption.' Enter the open password and re-run to do the decrypt-linearize-re-encrypt round trip.
File already linearized, Force off
Passed throughThe tool detects an existing /Linearized dictionary in the file header and returns the input unchanged. This keeps redeploys cheap. Tick Force to rebuild the hint stream regardless.
qpdf returned warnings
SupportedExit code 3 means warnings only — qpdf still produced valid linearized output. The tool accepts codes 0 and 3 as success. The file is safe to publish.
Damaged PDF won't parse
ErrorA truncated or corrupted file makes qpdf exit 2. Run PDF Repair to rebuild the structure first, then linearize the repaired output for the web.
Document under ~1 MB
Minimal benefitBrowsers fetch sub-megabyte files fast enough that the early first-page paint is barely noticeable. Linearization is harmless but the visible win is on the multi-megabyte documents that take real time to load.
Tagged / accessible PDF
PreservedLinearization reorders bytes; it does not strip structure tags, alt text, or reading order. An accessible PDF stays accessible after web optimisation — screen-reader behaviour is unchanged.
Frequently asked questions
What does 'optimise for web display' mean in this tool?
Specifically, linearization — reordering the file's bytes so a browser viewer can render the first page before the whole document downloads. It does not compress, scrub metadata, or change content; those are separate tools.
Which browsers benefit?
All the major built-in viewers — Chrome and Edge (PDFium), Safari (PDFKit), and Firefox (pdf.js) — render a linearized PDF progressively when your server answers byte-range requests. They all open non-linearized files too, just without the early first-page paint.
Will optimising affect accessibility?
No. Linearization is a structural byte-ordering change, not a content change. Tags, alt text, reading order, and the bookmark outline are all preserved, so screen-reader behaviour is unaffected.
Should I compress before optimising?
Yes, if the file is large. Linearization does not reduce size, so compress first — lossless for text-heavy PDFs, aggressive for scans — then linearize the smaller file last so the byte ordering survives.
Is web-optimised the same as PDF/A?
No. PDF/A is an archival conformance standard about self-containment and long-term readability; linearization is a delivery optimisation about byte order. A file can be both — linearize a PDF/A produced by the PDF/A converter if it is also web-served.
Is anything uploaded?
No. qpdf-wasm runs in your browser tab, so the document never leaves your machine. That holds even for documents you intend to publish — the file only goes to your server when you upload the downloaded output yourself.
Why is there no quality or size option?
Because this tool only linearizes, and linearization has nothing to do with quality or size — it reorders structure. The only two controls are a password field for encrypted inputs and a Force checkbox. For size, use the compression tools.
What does the Force checkbox do?
It re-linearizes a file even if it already has the hint stream. Normally the tool skips already-linearized inputs and returns them unchanged; Force makes qpdf rebuild the hint stream from scratch — useful after editing a previously-linearized file elsewhere.
Does it work on encrypted PDFs?
Yes — supply the open password and qpdf decrypts, linearizes, and re-encrypts in one pass. The output remains encrypted with the same password. Without the password an encrypted input fails to process.
Will the optimised file open in older readers?
Yes. A linearized PDF is a fully standard PDF and opens identically everywhere. Older readers that don't implement progressive rendering simply load it normally — they're never broken by linearization.
How do I confirm it worked?
Open the file in Acrobat or Reader → File → Properties → Description and look for 'Fast Web View: Yes'. That field reflects the /Linearized hint dictionary the tool wrote.
What size of PDF can I optimise?
Free allows 2 MB / 50 pages, Pro 50 MB / 500 pages, Pro Media 500 MB / 2,000 pages, Developer 2 GB / 10,000 pages, Enterprise unlimited. Processing runs in WebAssembly in your tab, so above those caps the practical limit is browser memory.
Privacy first
All PDF processing runs locally in your browser using PDF-lib and pdf.js. No file is ever uploaded — only metadata counters are saved for signed-in dashboard stats.