Split PDF — Extract Pages Free Online

Splitting a PDF is the operation that comes up the moment a document needs to do less than what it currently contains, and it shows up far more often than the obviously-related merge operation. The reasons are mostly mundane: the recipient only needs page 12 of a 200-page report, the legal team only wants the signed last page rather than the entire contract, the tax accountant only needs the relevant section of the year's bank statements, the school assignment only requires the appendix tables and not the main body. In all of these the underlying file is fine — well-formatted, internally consistent, structured the way the original author intended — but the recipient's needs are smaller than what the file delivers, and sending the whole document just adds noise to the exchange.

The range syntax is the part that makes this tool genuinely useful versus simpler alternatives. Most desktop PDF readers offer a 'print to PDF, only print pages X-Y' workflow that's serviceable but slow, and they always require manually opening the file before extraction. The text-based range syntax here handles the common cases efficiently: '5' for a single page, '5-10' for a continuous range, '5,7,12' for non-contiguous selection, '5-10,15,20-25' for combinations, '5-' for 'page 5 to the end of the document', '-10' for 'beginning to page 10'. Once you learn the syntax, expressing arbitrary page selections takes seconds rather than minutes, and the mental model maps directly onto how page references show up in the file's table of contents anyway.

Preset operations cover common patterns that come up across many workflows. Odd-only and even-only extraction is useful for re-binding a printed document where one side jammed in the printer. First-half and second-half extraction handles the case of a long document that needs to be reviewed in two passes by different people. Every-Nth-page extraction (every 5th page, for example) is occasionally needed for sampling or visual inspection of long archives. Single-page-per-file extraction (split into one file per page) is the right setting for documents that need each page handled independently downstream — a bundle of receipts where each receipt is one page, an exam booklet where each question is its own page, a legal exhibit where each page becomes its own numbered exhibit.

Use cases that benefit specifically from splitting are predictable once you start cataloguing them. Contract review where only signed pages need to be archived separately. Discovery preparation where specific pages need to be marked as exhibits. Research workflows where individual papers need to be extracted from a downloaded conference proceedings PDF. Tax preparation where specific bank statement pages need to be sent to the accountant. School and university uses where one chapter of a textbook needs to be shared without distributing the entire book. Genealogy research where specific pages of a long family record need to be cited. The pattern in all of these: the original document is too much, the recipient needs a slice, and the slice needs to look like a clean standalone PDF rather than 'pages 47-52 of something larger'.

The technical detail worth understanding is that the split operation copies the existing PDF object streams rather than re-rendering pages. The output PDF contains exactly the same bytes for the extracted pages as the source PDF did — same fonts, same images, same vector content, same metadata fields where appropriate. This matters because re-rendering would introduce subtle differences (font substitutions if the source used embedded fonts that don't survive a re-render, slightly different image compression, lost metadata), and the goal of splitting is preservation of the existing content, not re-creation. The tool here uses the copy-streams approach by default, which means the output is byte-identical to the input for the pages selected.

Bookmarks and table-of-contents entries deserve a moment because they distinguish a clean split from a messy one. Source PDFs with bookmark hierarchies should produce output PDFs where the bookmarks pointing to extracted pages are preserved and the bookmarks pointing to non-extracted pages are removed. The result is a navigationally usable output rather than a flat file with broken or missing bookmarks. The path here handles bookmark preservation where the source file has them, which means a 50-page extracted section from a 500-page book retains the table-of-contents structure for those pages rather than becoming an unstructured stack.

Single-file-per-page extraction is the mode that comes up most often for receipt-bundle processing and similar workflows. A scanned PDF of a month's worth of receipts where each receipt is one page; the user needs each receipt as a separate PDF for individual upload to an expense system. A scanned PDF of a multi-form document where each form needs to be processed separately. A scanned PDF of test results where each result needs to go to a different recipient. The split-per-page mode handles these cases cleanly, producing a folder (or zip) of individual PDFs named consistently so the order is preserved on disk.

There's a small but important detail about how naming works in multi-output splits. Files are named consistently — page-001.pdf, page-002.pdf, ... — so that they sort correctly when the recipient downloads the bundle and looks at the folder. Inconsistent naming (page-1.pdf, page-2.pdf, ... page-10.pdf, page-11.pdf would sort 1, 10, 11, 12, 2, 3 alphabetically) is a small but persistent annoyance that comes up when amateur split tools produce 'page1.pdf, page2.pdf'. Padding numeric filenames with leading zeros is the standard fix for that, and the path here applies it automatically.

Recompression as a post-split step matters more for some splits than others. Extracting 5 pages from a 500-page report typically produces a small file regardless of compression settings, because the source pages weren't doing the heavy lifting on file size. Extracting half of a heavy image-laden document might produce something large enough to want compression before sharing, particularly if the share channel is email. The optional recompression step in the split workflow handles this in one operation rather than requiring a separate trip through a compression tool afterwards.

There's an interaction with bookmarked sections worth flagging because it makes complex splits much faster. PDFs that include a hierarchical bookmark structure — chapter headings, section headings, sub-section headings — let you navigate sections by name rather than by page number. The split tool can use those bookmarks as natural break points: 'extract chapter 3' is more meaningful than 'extract pages 87-142', and the bookmark-driven approach is robust against page numbering changes if the source document gets updated. For research workflows where the same set of long PDFs gets re-split into specific chapters multiple times over months, learning the bookmark navigation pays back the small upfront effort.

A small operational note for split-per-page mode: the resulting bundle is delivered as a ZIP archive rather than as a series of individual download prompts. Most modern browsers and operating systems unzip archives transparently, so the practical difference for the user is one click on the bundle versus dozens of clicks on individual files. The ZIP also keeps the file order preserved on disk regardless of how the file manager sorts entries, which matters when the per-page split is going to be opened by a tool that expects pages in a specific sequence.

Operationally the tool takes a single drop. Upload the PDF, specify the pages to extract using the range syntax or a preset, optionally choose split-per-page mode, optionally enable recompression, click extract, download the result. Files are processed in temporary storage, links expire quickly, no signup is required, no watermark is added, no per-day quota counts down in the background. Multiple PDFs can run through one after another, useful when extracting specific sections from several documents in one sitting rather than handling a single one-off extraction. Most extractions complete in a few seconds; large multi-hundred-page sources with complex range selections take proportionally longer but still finish in a single pass.