Free PDF Splitter
Split PDFs into individual pages or custom ranges instantly. Extract pages without uploading to any server.
Supports PDF files up to 100 MB
How It Works
- Select or drop a PDF above.
- Choose to extract all pages or specify custom page ranges.
- The PDF is split in your browser · nothing is uploaded to any server.
- Download your split PDFs automatically as a ZIP file.
When to Use PDF Splitter
- Extract specific pages · Remove unwanted pages from a document.
- Share individual pages · Send only the relevant pages to someone.
- Reduce file size · Split a large PDF into smaller, more manageable files.
- Organize documents · Separate a multi-section PDF into individual documents.
- Archive management · Break down scanned documents into single-page PDFs.
Understanding Page Ranges
The custom ranges feature lets you extract specific pages. Use commas to separate multiple ranges:
- 1 · Extract page 1
- 1-3 · Extract pages 1, 2, and 3
- 5, 7-10, 15 · Extract page 5, pages 7–10, and page 15
- 2, 4, 6 · Extract every other page starting from page 2
Frequently Asked Questions
How many pages can I split at once?
You can split PDFs with up to hundreds of pages. The limit depends on your browser's memory, but most PDFs will process instantly.
What file size limit applies?
PDFs up to 100 MB can be processed. Since splitting happens in your browser, very large files may take a moment depending on your device.
Is my PDF uploaded anywhere?
No. All splitting happens completely in your browser. Your PDF never leaves your device, ensuring complete privacy and security.
Can I extract pages in a different order?
Yes. In custom ranges mode, enter page numbers in any order: for example, "5, 3, 1" will create a PDF with pages 5, 3, and 1 in that order.
What happens to PDF forms and annotations?
The text and layout are preserved, but interactive forms may not carry over. Annotations are generally preserved during splitting.
Four meanings of "split"
The verb "split" in a PDF context covers at least four distinct operations, and tools that use the same word in their interface deliver quite different outputs. Burst breaks the PDF into N single-page PDFs, one per page, each named with the page number. Range extraction picks one or more page ranges (e.g., pages 1-10 and 25-40) and produces a single PDF for each range. Chapter split by bookmark reads the document outline tree, finds the page ranges each top-level bookmark covers, and produces one PDF per chapter. Custom selection picks an arbitrary subset of pages, possibly out of order, into one combined PDF.
This tool implements range extraction. The user specifies page ranges, the tool builds one output PDF per range, and the original is never modified. Burst is achievable by specifying every page as its own one-page range, but the user interface is optimised for range work because that is the dominant real-world use. Custom selection (arbitrary page reordering inside one file) is the job of the PDF Page Editor tool; bookmark-driven chapter splits are not yet supported here, which the body copy below explains in honest terms.
A short history of splitting
Splitting predates PDF as a format by about a decade. Document-imaging vendors had been extracting page ranges from multi-page TIFFs and PostScript files since the late 1980s, with the same fundamental problem to solve: copy the visual content of certain pages into a new container without breaking the cross-references that bind that visual content to its resources. PDF, when it arrived in 1993, inherited the problem and most of the algorithmic machinery from that earlier work.
The canonical command-line tool for PDF manipulation in the early 2000s was pdftk, written in Java by Sid Steward in 2002. pdftk had explicit split, merge, rotate, and watermark operations, all implemented by parsing the PDF into an object model and re-emitting the relevant subgraph. qpdf, started in 2008 by Jay Berkenbilt, became the modern open-source standard, exposing the same operations through a C++ library used by package managers worldwide. ISO 32000-1 in 2008 added no splitting-specific primitives because the existing format constructs were already sufficient; splitting is purely an authoring-side operation that produces a smaller, valid PDF using the same building blocks.
How the split actually happens
The split operation in this tool runs three deterministic passes inside pdf-lib. First, the source PDF's cross-reference table is read and every indirect object is parsed into an in-memory model. Second, for each requested output range, the tool creates an empty destination document, calls copyPages with the page indices in the range, walks each chosen page's resource graph (fonts, images, form XObjects, graphics-state dictionaries, patterns, color spaces) to copy every transitively referenced object into the destination's numbering space, and appends the copied pages to the destination's pages tree in order.
Third, each destination is serialised to bytes and emitted as a download. Per-range destination documents are eligible for garbage collection between iterations, which is what makes the tool work on PDFs whose total page count would not fit in memory if every output were kept simultaneously. The page-copy operation is the same primitive that powers the PDF Merge tool on this site, used in the opposite direction. Both operations are lossless: the text, images, vector graphics, and content streams of the copied pages are written verbatim into the destination, no transcoding or rasterisation occurs, and the output renders pixel-identical to the corresponding pages of the source.
Real-world workflows that drive splitting
- Exhibits in legal filings. When a court motion is filed with exhibits A through Z, the master PDF that the lawyer assembled has to be broken into individual exhibits for indexing in the court's electronic case-management system. The US Federal Courts' CM/ECF guidelines explicitly suggest splitting before upload because the indexing system tags each exhibit separately.
- Exam papers and answer keys. Exam boards distribute the question paper, mark scheme, and examiner's report as a single combined PDF for archival. Schools then split the file by section to distribute to different year groups. This is one of the highest-volume splitting patterns in absolute terms, peaking in the summer exam cycle.
- Individual statements from a batch. Banks, utilities, and payroll systems often generate a single monthly batch PDF containing every recipient's statement, then split it server-side. The same operation is sometimes needed on the recipient's end when a tax-prep service receives a combined-year statement and needs the per-quarter pages.
- Chapter and article extraction. University staff distribute a journal volume or textbook scan by chapter, often to stay within copyright-friendly fair-use limits. Bookmark-driven splitting is ideal here; users with range-based tools fall back to manual lookup of chapter starts.
- Public-records and FOIA workflows. Government records officers receive large internal documents to release publicly, then split them at sensitive section boundaries to release the non-sensitive parts immediately while the others are processed for redaction with a separate tool.
- Sample portfolios. Photographers and designers maintain a master portfolio and split out a small sample for specific pitches. Lower volume than the other use cases, but the per-user value is high because the alternative is keeping multiple master files.
Common pitfalls and workarounds
- Form fields go dead. The interactive-form dictionary lives at the document level. When pages containing form widgets are copied, their visual artefacts come across but the field definitions that make them interactive do not. The split outputs render the forms correctly but will not accept input. Fix: flatten the source first with the PDF Flatten tool, then split the flattened copy.
- Bookmarks disappear. The outline tree is a document-level structure. Range-based splitting does not currently propagate the relevant subtree of the outline into each output, so each split file has no outline regardless of whether the source had one. Outline-aware splitting requires either a partial outline-rewriting pass or a different mode entirely, and is deferred for now.
- Encrypted PDFs fail to load. A PDF with an open password cannot be parsed until the password is supplied. This tool does not support encrypted input. Workflow: use the PDF Unlock tool to remove the protection first, split the unlocked copy, and optionally re-apply protection with PDF Protect on each output.
- Signatures do not survive. A digital signature is a cryptographic hash of an exact byte range of the input file. Splitting produces new PDFs by definition, and those new PDFs do not contain the original's bytes; the signature is not preserved in any of the outputs. This is the cryptographically correct behaviour but is sometimes surprising. Keep signed source PDFs intact and split unsigned copies if you need them split.
- Accessibility tags are not propagated. The PDF/UA-1 structure tree that drives screen readers is a document-level object. Range-based splitting does not propagate it into the outputs, so a tagged source produces untagged splits. For documents that will be redistributed to readers with visual impairments, you'll want to re-tag each output through Adobe Acrobat's "Make Accessible" wizard.
Why the split parts total slightly more than the input
Each output PDF is a complete, valid PDF in its own right: it has its own catalog, its own page tree, its own font metadata, and its own cross-reference table. Splitting a 10 MB PDF into 10 single-page outputs typically produces files totaling slightly more than 10 MB, because each of those 10 files carries the structural overhead of being a self-contained document. Empirically the overhead lands in the range of 1 to 5 percent of the total, and it grows in absolute terms with the number of output files. For most use cases this is negligible; for users splitting extremely large documents into many small ones, it is visible. Anyone for whom the total size matters can run each output through the PDF Compress tool afterwards to recover most of the per-file overhead.
Browser-only versus cloud splitting
The cloud PDF splitters that fill Google's search results (Smallpdf, ILovePDF, PDF24's web app, Adobe Acrobat Online, Sejda's free tier) all upload your source PDF to their servers, perform the split there, and serve the outputs as downloads. Their privacy policies state that uploaded files are deleted within a few hours, but the files transit the operator's network, exist on their disks for the processing window, and pass through whatever logging the operator maintains for abuse detection.
This tool does not upload. Your PDF is read into the browser tab through the standard File API, parsed by pdf-lib in the same tab, and the output PDFs are written back to your disk through the standard download API. The only network traffic during a split is the one-time CDN load of pdf-lib when the page first opens. You can verify it: open the browser's developer tools to the Network tab, run a split, and watch that no requests fire with your file content. The cost of the privacy guarantee is the missing features (bookmark-aware splitting, structure tree propagation) that the larger server-side tools provide; the trade-off is honest, and you can pick whichever side of it matters for the particular document.
More frequently asked questions
Can I split by bookmark or chapter?
Not currently. This tool does range-based splitting; you pick page ranges and it produces one output per range. Bookmark-aware splitting (where the tool reads the document outline and uses each top-level bookmark's page range as a split point) is a feature we plan to add but is not yet shipped. The workaround for now is to open the PDF in a reader, note the chapter start pages from the visible outline, and enter those ranges manually. For documents with deep outlines, a server-side tool like Smallpdf or Adobe Acrobat Online may save you the lookup step.
Why do my split files total slightly more than the original?
Each output PDF carries the structural overhead of being a self-contained document (catalog, page tree, cross-reference table, font metadata). Splitting a 10 MB file into 10 one-page outputs produces a set of files that total a few percent more than the input. Typically the overhead is in the 1 to 5 percent range; it grows in absolute terms with the number of outputs. If the total size matters, run each output through the PDF Compress tool to recover most of the per-file overhead.
Will the split keep my bookmarks and tagged accessibility?
Not currently. The outline tree and the PDF/UA-1 structure tree are both document-level objects. The pdf-lib copyPages operation that this tool uses does not yet propagate either into the split outputs. For documents where bookmark and tag preservation matter (public-sector publishing, accessible document distribution), Adobe Acrobat Online is the right tool today. For most splits, the loss is acceptable; for some, it's not, and we don't want to pretend otherwise.
Can I split encrypted or password-protected PDFs?
Not directly. A PDF with an open password cannot be parsed until the password is provided, and pdf-lib does not currently support encrypted input. The workflow is: use the PDF Unlock tool to remove the password, split the unlocked copy here, and optionally re-apply protection with the PDF Protect tool on each output. The split copies are different documents from the original signed-and-encrypted one, so signature validity and access controls are not preserved across the round trip.
What's the naming convention for the output files?
The output names are generated from the source PDF's base name plus a suffix indicating the range. A source named annual-report.pdf split into pages 1-5 and 6-30 would produce annual-report_pages_1-5.pdf and annual-report_pages_6-30.pdf. Single-page extractions get a suffix like _page_7.pdf. The naming is deterministic so that batch workflows can predict the output names from the range specification. The browser's "Save As" dialog determines where each file lands; most modern browsers offer a per-tab download folder preference and will use that for every output.