A client asked me for "the warranty section" of a product manual last month. The manual is 90 pages. What I almost did — what I have done for years — is attach the whole 90 pages and write "see page 61." What I did instead took about forty seconds: split out pages 58–64 and sent a 7-page file with exactly the section in it.
Splitting PDFs by page range is one of those operations that sounds trivial and still eats time, because the friction is never the split itself. It is figuring out the right range, verifying you got the right pages, and doing it again for the next document. Here is the workflow that made it a habit instead of a chore.
The range is the hard part
"Pages 58–64" assumes the PDF's page numbers match the numbers printed on the pages. They often do not: covers, unnumbered front matter, and a table of contents shift everything by two or three. Before splitting anything, open the document, scroll to the first page you need, and read the viewer's page counter — that number, not the printed folio, is what every split tool wants. Note the start and end from the viewer, then add nothing. Most "my split came out wrong" stories are an off-by-two nobody checked.
The split itself
I use the split tool on PDFLean for this: upload, enter the range, download the extracted pages as their own file. The same operation exists in most PDF toolkits — qpdf input.pdf --pages . 58-64 -- out.pdf does it from the command line, and if you do this daily, scripting it with fixed ranges per document type is worth the ten minutes. Two modes to know the difference between:
- Extract one range gives you a single new PDF with just those pages. This is the 90% case: one section, one recipient.
- Split into parts cuts the file at intervals — every 10 pages, or at bookmarks. That is for distribution workflows (one chapter per reviewer), not for answering a question.
Verify like you mean it
A split that "ran successfully" can still be wrong, and you will not hear about it — your client will just read the wrong section politely. Thirty seconds of checking:
- The output's page count equals end − start + 1. If it does not, the range was interpreted differently than you expected.
- Open the output and look at the first and last page. They should be the pages you saw in the viewer, not the pages whose printed numbers match your range.
- Check the file size is sane. A 7-page extract that is 80% of the original's size means the source carries heavy shared resources (fonts, images) — harmless, but worth knowing before you promise someone a "small" attachment.
When splitting is the wrong tool
If the recipient needs the pages in a different order rather than a subset, that is a rearrange job. If the same extract goes out repeatedly with fresh data each time — a monthly statement section, say — the bottleneck is regenerating the source, and the split should be the last step of that pipeline, scripted, not a manual errand. And if what they actually need is one table as data, no page range fixes that; it is an extraction problem wearing a splitting costume.
The whole habit reduces to one sentence: send people the pages that answer their question, numbered the way their viewer counts them, and check the two ends before the file leaves. The 90-page attachment with "see page 61" is how documents get read by nobody.
Top comments (0)