← All posts

Split a PDF that is too big to even open

The file is 380 MB. You double-click it and the reader shows a grey rectangle and a spinner, or it draws the first page and then stops responding the moment you scroll. On the older machine in the office it does not open at all.

So you searched, and every answer says compress it first. Which would be sensible, except that a compressor has to open the file too — and the browser ones want you to upload all 380 MB before they even try.

Splitting is the right instinct. It just has to be aimed at the right problem, because "too big to open" describes three different files and only one of them gets better when you cut it into pieces.

Opening a PDF is two jobs, and only the second one is expensive

This is the part nobody explains, and it decides everything else.

Parsing is reading the structure. The reader jumps to the cross-reference table at the end of the file, learns where every object lives, and walks the page tree to find out how many pages there are and how big they are. The cost of this is proportional to the number of objects, not to the number of megabytes. Parsing a 400 MB file with forty pages in it takes a moment.

Rendering is drawing a page you are looking at. This is where the money goes, because every image on the page has to be decompressed into raw pixels before anything can be scaled or painted. Compressed on disk, an image is a few megabytes. Decoded, it is width × height × three bytes, and nothing about the compression is relevant any more.

Do the arithmetic on the file that is hanging your reader. An A4 page scanned at 300 dpi in colour is 2,480 × 3,508 pixels — about 26 MB of memory. The same page at 600 dpi is 104 MB. An A0 drawing scanned at 600 dpi is roughly 19,800 × 28,000 pixels, which is 557 megapixels, which is 1.6 GB of memory for one page. On disk that page might be 40 MB of JPEG. The reader is not choking on 40 MB. It is trying to find 1.6 GB.

And here is the useful consequence: copying a page from one PDF into another never decodes the image. The compressed object is lifted across as it stands. That is why a splitter can cut a file that your viewer cannot display, and why "you cannot split it because you cannot open it" is wrong. The splitter is not opening it in the sense you mean.

Three files wearing the same costume

Heavy. A few hundred megabytes across a handful of pages: large-format drawings, a 600 dpi colour scan, a page with an enormous aerial photograph on it. Each page is individually too big to render. Splitting produces smaller files that each still contain the page that will not display, so it fixes nothing. This one needs fewer pixels, not fewer pages.

Long. Thousands of pages at a modest weight — a disclosure bundle, a scanned archive, a printed system log. No single page is difficult. The reader stalls on the whole document: Acrobat builds a page-label tree and starts generating panel thumbnails, each of which is a render, and a browser viewer keeps the entire file in one tab's memory alongside them. This is the file splitting was invented for, and each part opens instantly.

Broken. Not actually big at all, or big for no visible reason. When the cross-reference table does not match the file, a reader falls back to scanning the whole thing from the start looking for object headers so it can rebuild the index itself. On a large file that takes minutes and looks exactly like a hang. A file that is much bigger than its contents justify is usually a form that has been saved fifty times, each save appending a new copy of the changed objects and orphaning the old ones. Repair PDF rebuilds the document around the pages it can actually read and leaves the unreachable material behind. If the file is 0 bytes, none of this applies and there is nothing to repair.

There is a fourth case that looks like all three: the file opens fine on your desktop and spins forever in a browser, SharePoint preview or webmail. That is usually linearisation. A linearised file — "fast web view" — puts the first page's objects and a hint table at the front, so a viewer can draw page 1 after a few hundred kilobytes. A file that is not linearised keeps its index at the end, so an online viewer needs the whole thing before it can show anything. qpdf --linearize in.pdf out.pdf fixes that without changing a single page.

Work out which one you have, before you upload anything

  1. Get the page count and the page sizes. Our PDF inspector reads the file in your browser and uploads nothing, which matters when the file is 400 MB. It reports the page count, the size of each page, whether the document is encrypted and whether there is a real text layer. It parses; it does not render, so a file that defeats your reader usually still reports. If the tab itself runs out of memory, that is a finding too — go to the command line below.
  2. Divide megabytes by pages. Under about 200 KB a page and in the thousands of pages: you have a long file. Ten megabytes or more a page: you have a heavy one. A hundred pages at 40 KB each that still will not open: you have a broken one.
  3. Look at the page sizes the inspector lists. Anything much larger than A3 is a drawing or a poster, and drawings are where the 500-megapixel pages live.
  4. If you have poppler installed, pdfimages -list in.pdf prints every image in the document with its pixel dimensions and its effective dpi. One line will be much larger than the rest. That is the page your reader died on.

Cutting a long document into parts that open

Under the ceiling, pick by what you know:

Read the notes on the result. If Split PDF by size tells you that page 12 is bigger than your limit on its own, and gives it a file to itself, you have just found your monster page — that is the heavy case, and it is the page that was hanging your viewer all along.

Over 50 MB, do it locally — it is one line

None of these decode an image, so all of them run on a file far larger than the memory in your machine. All are free and all run on Windows, macOS and Linux.

For the heavy case, the fix is fewer pixels, and Ghostscript is the tool: gs -sDEVICE=pdfwrite -dPDFSETTINGS=/ebook -o out.pdf in.pdf downsamples every image in one pass. Expect it to take a while on a file like this — unlike the commands above, it does decode everything. Our Compress PDF does the same kind of work under 50 MB, though be clear-eyed about what it can achieve: a file that is large because it is long rather than heavy will not move at all, and no setting changes that.

What splitting will not do

It never makes the total smaller. The parts add up to more than the original. Each part is a new document, and shared objects have to be copied into every part that references them. A font embedded once in the whole document is now embedded once per part; a scanned letterhead drawn on every page is copied into all of them. Ten parts of a 40 MB file might come to 44 MB. If a total size limit is what you are fighting, splitting is the wrong lever.

It does not carry the outline or the form fields across. Bookmarks point at pages that are no longer in the file, so they are dropped, and so are field definitions. Flatten a filled form before you split it if the answers matter.

It does not help the heavy case at all. Worth repeating because it is the mistake this question produces most: cutting a 40-page drawing set into eight files gives you eight files that each fail to render exactly as before.

Fixes that do not touch the file

Sometimes the document is fine and the reader is the problem.

Then split it properly once, with the right tool for whichever of the three files you turned out to have — and keep the parts, because you will be opening this document again.

Tools this post uses: