How to Split a PDF Into Multiple Files (One File Per Chapter or Range)

"Split a PDF" sounds like one job, but in practice it's two different jobs that just happen to share a name. Sometimes you want a single new PDF that contains only pages 4 through 9 of a bigger file — a form, an exhibit, a chapter you need to send on its own. Other times you actually want several separate files out of one document — one PDF per chapter of a report, one per invoice in a scanned batch, one per section of a contract for different reviewers. Most free PDF tools only handle the first case, quietly forcing you into painful workarounds — running the tool five separate times, or extracting everything into one file and then trying to re-split it in a different program — for the second. This guide covers both properly: how page ranges actually work, how to get several output files in one pass instead of one, and the mistakes that turn a clean split into a folder full of confusingly-numbered PDFs.

The two things people mean by "split a PDF"

It's worth being precise about this before touching any tool, because the two use cases genuinely need different settings. Extraction is when you want one output file containing a subset of pages from the original — you're pulling something out, and everything else gets discarded. A classic example: your bank statement PDF is 40 pages covering a full year, but you only need pages 12 through 14 for a loan application, so you extract just those three pages into a new, much smaller PDF. Multi-file splitting is when you want the original document broken into several separate files, each one keeping its own set of pages — nothing is discarded, it's just reorganised into smaller pieces. A 120-page training manual with 8 chapters becomes 8 separate chapter PDFs, each independently shareable, without you manually running an extraction tool eight times and renaming each output by hand.

Step-by-step: extracting specific pages into one file

This is the simpler, more common case, and it's what most people mean the first time they search for a PDF splitter.

1. Upload your PDF to a splitter — our PDF Split tool runs entirely in your browser, so nothing leaves your device, which matters if the document has financial, medical or legal content.
2. Check the page count shown after upload against what you expect — if it doesn't match, the file may be a scanned image bundle or have hidden blank pages you'll want to account for.
3. Enter the pages you want in the range field — a single range like "4-9", a single page like "12", or a comma-separated mix like "1-3, 7, 10-12" to pull several non-adjacent sections into the one output file.
4. Extract and download — you get one new PDF containing exactly the pages you specified, in the order you specified them, with everything else left out.

Step-by-step: splitting into multiple separate files

This is the case most tools skip entirely, forcing you to repeat the extraction process manually for every chapter or section — which is slow, and easy to get wrong when you're juggling several ranges by hand and renaming files as you go. A proper multi-file split lets you define every range up front and get all the output files in a single pass.

1. Open the tool and switch to its multi-file / "split into files" mode rather than the single-extraction mode.
2. List every range you want as a separate output, one per line — for an 8-chapter manual this might be "1-12", "13-24", "25-33" and so on, one line per chapter's page range.
3. Double-check the ranges don't overlap unless you actually want a page to appear in more than one output file — accidental overlap is the single most common mistake in this workflow.
4. Run the split — you get every defined range as its own PDF, typically packaged together in a single ZIP download so you're not saving files one at a time.
5. Rename the files from inside the ZIP if the tool doesn't already label them meaningfully — a default name like "split-1.pdf" is fine for a quick job, but for anything you're archiving or sharing, a real name like "chapter-3-methodology.pdf" saves confusion weeks later.

Reading and writing page ranges correctly

The range syntax looks trivial and is exactly where most mistakes happen, because it's easy to be one page off in either direction without noticing until you open the output.

• A range like "4-9" is inclusive on both ends — it includes page 4, page 9, and everything between, for a total of 6 pages, not 5. Off-by-one errors here are the most common mistake in the entire workflow.
• Commas separate independent selections — "1-3, 7, 10-12" means pages 1, 2, 3, 7, 10, 11 and 12, in that exact order, with page 8 and 9 deliberately excluded.
• Duplicate pages are usually silently deduplicated by a well-built tool — entering "5, 5, 5-7" should produce pages 5, 6, 7 once each, not page 5 three times. If a tool doesn't do this, treat its range parsing with more suspicion generally.
• Order in the input generally controls order in the output for extraction — entering "10-12, 1-3" typically produces a file with pages 10, 11, 12, 1, 2, 3 in that sequence, which is occasionally useful (reordering a document) but easy to do by accident if you weren't expecting it.
• A range that exceeds the document's actual page count should be clamped or flagged, not silently produce a broken file — if your document has 40 pages and you enter "35-50", a reliable tool extracts pages 35 through 40 and ignores the non-existent pages 41 through 50, rather than erroring out or producing a corrupted result.

Common mistakes that turn a clean split into a mess

• Splitting before proofreading the original — if a page is missing, duplicated or out of order in the source PDF, splitting just propagates that mistake into every output file, and now you have several files to fix instead of one.
• Not accounting for a cover page or blank pages when calculating chapter boundaries — a manual's "Chapter 1" section header being on the physical page 3 rather than page 1 throws off every subsequent range if you don't check the actual PDF page count for each section first.
• Overlapping ranges by accident in a multi-file split — entering "1-15" and "15-30" as separate chapters means page 15 appears in both output files, which is usually not what you wanted and can confuse anyone reading both files independently.
• Forgetting that splitting doesn't shrink file size proportionally — a heavily-compressed 50MB PDF split into 5 equal chapters won't automatically produce five 10MB files if the original's size came from a few image-heavy pages concentrated in one section rather than spread evenly.
• Uploading a sensitive document (medical records, signed contracts, financial statements) to a tool that processes files on a server rather than in your own browser — for anything you wouldn't want stored on someone else's infrastructure indefinitely, a client-side tool that never uploads the file is the only version of "free" worth trusting.
• Renaming output files with a scheme that doesn't sort correctly — "chapter-1.pdf" through "chapter-11.pdf" sorts as 1, 10, 11, 2, 3… alphabetically in most file browsers unless you zero-pad the numbers ("chapter-01.pdf"), which becomes genuinely annoying once you're past nine files.

What happens to bookmarks, forms and fonts when you split

A well-built splitting tool preserves the actual page content exactly — text stays selectable, embedded fonts stay embedded, and images keep their original resolution, since splitting is a page-extraction operation, not a re-render or re-compression. What generally doesn't survive the split automatically is anything that referenced the document as a whole: PDF bookmarks/outline entries that pointed to page 45 in the original file won't magically know that page 45 is now page 3 of a new file, and internal hyperlinks that jumped to another page in the same document may break if that target page ended up in a different output file. Fillable form fields usually do survive on the pages that contain them, since they're page-level content, but any calculation or validation logic that referenced a field on a page that's now in a different file will stop working correctly, since it can no longer see that other field. If bookmarks and cross-references matter for your use case, it's worth opening each output file afterward and doing a quick spot-check rather than assuming everything carried over cleanly.

Splitting vs compressing — you often want both

These solve different problems and it's worth not conflating them. Splitting reduces file size only as a side effect of having fewer pages in each output — a 200-page, 80MB PDF split into ten 20-page files gives you ten roughly-8MB files, useful for sharing individual sections, but it doesn't make the total content any smaller. Compression, by contrast, re-encodes the images inside the PDF at a lower quality or resolution to shrink the actual file size while keeping every page. If your real goal is "this file is too big to email," and you only need to send a subset of pages, splitting alone probably solves it. If you need the entire document to be smaller — for archiving, for a slow connection, for an upload size limit — you want PDF compression, and if you need both a smaller file *and* fewer pages, running compression first and splitting the result afterward is generally the more efficient order, since you're compressing once rather than compressing every split file separately.

Doing this privately instead of uploading to a random website

A meaningful share of the PDFs people want to split are exactly the ones you'd least want sitting on an unfamiliar server: signed contracts, tax documents, medical reports, financial statements. Many free "PDF splitter" sites process files by uploading them to a server, running the split there, and sending the result back — which means your document, even briefly, existed on infrastructure you have no visibility into and no real assurance about, regardless of what the privacy policy claims. A tool that runs the split entirely inside your browser using client-side JavaScript never has this problem, because the file is never transmitted anywhere; the entire operation happens locally on your own device, and closing the tab is functionally equivalent to the file never having left your computer. For anything with even mildly sensitive content, that distinction is worth checking before you upload — most tool pages will say plainly whether processing happens locally or on a server, and if a site doesn't say either way, that's usually a sign it's uploading.

A practical workflow: splitting a long report for review

Put together, here's how the two modes combine for a common real scenario — sending a long report out to five different reviewers who each only need their own section. First, extract the full table of contents or index pages separately if you want to send those to everyone regardless of which section they own. Then switch to multi-file mode, list each reviewer's section as its own range (checking each boundary against the actual PDF page numbers, not the printed ones), and run the split once to get every section as a separate file in one download. Rename each output to something the reviewer will recognise at a glance rather than a generic "split-3.pdf," and send each person only the file that's actually relevant to them — smaller attachments, less scrolling for them to find their part, and no risk of someone accidentally editing or commenting on a section that isn't theirs.

The short version: know which of the two jobs you're actually doing before you start, double-check your page ranges against the file's real page count rather than any printed numbering, watch for overlapping ranges when producing several files at once, and prefer a tool that never uploads the document if there's anything in it you wouldn't want on someone else's server. Get those right and splitting a PDF — either into one focused extract or into a dozen clean chapter files — takes under a minute and produces exactly what you meant to produce.