Linearize PDF
Reorder the file so page one appears before the rest arrives.
This tool runs entirely in your browser. Your file is never uploaded, and you can verify that in your browser's network tab. Verify it yourself: open your browser's network tab and watch. You will see one small request asking whether you have tasks left - a tool name and a hash, never the file.
What this does
A linearised PDF is the same document with its objects in a different order. Everything the first page needs is moved to the front of the file, so a reader can draw page one while the remaining megabytes are still arriving. Nothing about the pages, the text or the images changes - open the result next to the original and you will not be able to tell them apart on screen.
Do it to any PDF you publish on a website, link to in an email, or hand to a viewer embedded in an app. It matters most for large files on slow connections, where a document that opens in two seconds and one that appears to hang for thirty are the same file in two different orders.
How it works
- Drop the PDF onto this page. Files up to 300 MB are accepted.
- Leave Also repack the file on. It recompresses the streams first, which usually takes another 10 to 25 per cent off the size.
- Press Linearize.
- The download starts on its own, with a -web suffix so you can tell the two versions apart.
- Upload the result as it is. No setting is needed to produce the effect, though your server must support byte-range requests for readers to use it.
The mechanism is ordering, not compression. In an ordinary PDF the objects sit wherever the producer wrote them and the index that finds them is at the end, so a reader over HTTP either waits for the whole file or asks for pieces of it in several round trips. Linearising puts a small hint table, the first page and every object that page depends on right at the front, followed by the rest in page order.
Repacking and linearising pull against each other, which is why the order of the passes matters. Object streams make a file smaller by packing many objects into one compressed block, and linearisation needs the first page's objects reachable on their own. The repack runs first and the linearisation last, so qpdf resolves the conflict rather than producing a file that claims to be linearised and is not.
The effect only exists if the server cooperates. Fast Web View depends on HTTP byte-range requests: the reader asks for the first part of the file, draws page one, then asks for more. A server that does not honour ranges sends the whole file regardless, and the linearised document behaves like the ordinary one. Most static hosting and every CDN supports ranges; some application frameworks streaming a file through their own handler do not.
If the repack fails on an unusual file, you still get the linearisation you asked for. Recompression is treated as a bonus rather than a requirement.
The job happens in your browser through qpdf compiled to WebAssembly, so the file you are preparing to publish - often still a draft - reaches no server before you put it on one.
What this tool cannot do
- The benefit only appears when the file is served over HTTP by a server that supports byte-range requests. Opening a linearised file from disk is no faster.
Questions people ask
- What does linearising actually do to the file?
- It rewrites the same content in a different order: a hint table and everything page one needs go to the front, the rest follows in page order. No page, image or character changes. The file is typically a little larger than a fully packed version, because some objects can no longer share a compressed block.
- Do I need this for a file I only email?
- No. Fast Web View only helps when a reader is fetching the document over HTTP a piece at a time. An attachment is downloaded in full before it opens, so linearising it changes nothing. Use it for anything you host, embed or link to.
- Does it make the file bigger or smaller?
- Both effects are in play. Linearisation adds a hint table and prevents some objects being packed together, which costs a little. The optional repack recompresses every stream, which usually saves 10 to 25 per cent on a file nobody has optimised. With repacking on, the result is normally smaller than what you started with.
- How do I confirm the file is linearised?
- Open the result in Acrobat and look at document properties: Fast Web View reads Yes. On the command line, qpdf --check reports the file as linearised. To test the real effect you also need to serve it over HTTP from a server that accepts range requests.
- Is the file uploaded anywhere?
- No. qpdf runs as WebAssembly in a Web Worker inside your browser, so the document stays on your device until you publish it yourself. The only request the page makes is the allowance check, which names the tool and carries a hash of the bytes.