Extract Pages From a PDF Without Buying an Editor

I pulled a single page out of a twelve page PDF last week. The source file was 50,105 bytes. The one page extract came back at 41,147 bytes.

Eight percent of the pages. Eighty two percent of the file.

Nothing had gone wrong, and I get to why below, but it was enough to send me into the code behind page extraction instead of carrying on with what I assumed it did. Most of the surprises have very little to do with pages. They are about what a page drags along behind it, and about a range parser that accepts input it cannot honour and then hands you a download without a word of complaint. Type 99 into the box on a twelve page document and you can still get a file back.

What follows is the range syntax as it behaves rather than as it is advertised, the inputs that misfire silently, what an extract quietly loses, and the free routes that beat a browser tab for certain jobs. All measured on real files.

What the page range box actually accepts

The form I picked apart is our own, so when I describe the parser, that is this specific parser. It runs on Python and PyPDF2 on the server, and it reads your range string in full before it touches a single page. If you want to pull a page range out of a PDF that is the code doing the work.

Four forms are understood, and they mix freely.

The trailing dash is the shortcut most people never find: 5- means everything from there on, useful when you have not counted the pages.

Two things people reach for are not there. No keyword for the final page, so end and last both fail, and text is rejected rather than guessed at. And no way to ask for every other page: want the odd pages of a forty page scan, and you are typing all twenty numbers.

The inputs that quietly give you the wrong pages

Read this section twice. The parser walks each comma separated chunk, drops valid page numbers into a set, and raises an error only when that set finishes completely empty. A half wrong range is still a successful range.

Row one is the one that bites. On a twelve page file, 1-3,99 gives you a three page PDF and calls it a success. The 99 is noted internally and then thrown away, because pages 1 to 3 rescued the request. Only if every number you typed is out of bounds do you see the error, and it is a good one when it comes: Page(s) 99 do not exist. This PDF has 12 page(s) (valid range: 1-12).

So the failure mode is asymmetric. Get it completely wrong and the tool tells you exactly what is wrong. Get it slightly wrong and you find out later, when someone asks where the appendix went.

The error rows are simpler. 10-1 looks like pages 10 down to 1, but it counts upwards, arrives nowhere and produces an empty set. 1-3-5 is not repaired as a malformed range, it is skipped as a chunk with the wrong number of parts.

You can extract pages from a PDF, but you cannot reorder them

Every page number lands in a set, and the set comes back out through a sort. Type 9,2,5 and you get pages 2, 5 and 9, in that order, every time. It is not a setting anybody forgot to expose. It is the shape of the code.

Pulling pages 3, 1 and 7 into a new running order is a real need, and no page range box will do it however you phrase the input. The command line tools below handle it in one line.

One PDF or a ZIP: the mode decides

Three ways to cut a file up, differing in how many things come out.

1. Extract a range. Whatever pages you name, gathered into one new PDF. Always a single file.
2. Split every N pages. A 100 page file at N of 10 gives you ten PDFs.
3. One file per page. Exactly what it sounds like.

Anything that produces more than one file gets zipped on the server, so modes two and three hand you a ZIP and mode one hands you a PDF. Inside the archive the names are padded to three digits, so you get report_part001.pdf and report_page007.pdf rather than part1 and page7. That padding is why your file manager lists them 1, 2, 3 instead of 1, 10, 11, 2.

A small workflow point. If you want three separate single page PDFs, do not run the extract three times. Run one file per page once and keep the three you wanted. Same result, one upload.

When extraction stops before it starts

Two categories get refused up front rather than half processed, which is the right call.

Password protected PDFs are rejected before any page is read, with a message telling you to strip the password off first and come back. Damaged files get caught the same way: a missing end of file marker, or an object reference pointing at nothing, and the job stops with a note to repair the file first.

One check never reaches the queue at all. Ask for an extract with an empty range box and the request is rejected on arrival, with the upload deleted rather than left sitting there.

Why the extract is barely smaller than the original

Back to those 41,147 bytes.

A page in a PDF is not a self contained thing. Its content stream is mostly instructions that point at resources kept in a shared pool: fonts, images, colour profiles. Extraction copies the page object, and then the writer has to follow every one of those pointers and write out what it finds. An embedded font that was serving all twelve pages gets written into your one page file in full.

My test document was text with a single TrueType font embedded across every page. Twelve pages, 50,105 bytes. One page out: 41,147 bytes.

Then I rebuilt the same document using only the standard fonts that are never embedded, and pulled two pages from twelve. 6,635 bytes down to 2,029. It shrank exactly as you would expect.

So the rule is not about page count. Extracts shrink in proportion to how much of the file was genuinely per page. A scanned photo book, where every page carries its own image, shrinks close to the ratio you expect. A 200 page report sharing one embedded font family and a logo will not. Nothing is recompressed on the way out either, so if a smaller file is the goal, extraction is the wrong lever and a compression pass afterwards is the right one.

The page you did not extract that is still in the file

This is the one I did not see coming.

I built a twelve page file where page 4 carries a link jumping to page 11, the sort of cross reference any report has. Then I extracted pages 4 and 5.

The result opens as two pages. Every viewer agrees it is two pages. But the file physically contains three page objects. The page tree lists two, and page 11 is in there as well, unlisted and unreachable, because the link on page 4 held a reference to it and the writer followed that reference while copying.

The link still draws as a clickable rectangle. It points at a page that exists in the bytes but not in the document, so clicking it goes nowhere useful.

Two things follow. If you are extracting pages precisely because the rest is confidential, an internal cross reference can carry an excluded page into your output, invisible but present. And it is one more reason the byte count looks wrong.

If that matters, the fix is the next section: reprint the extract. Printing rebuilds the file from the pages actually in the page tree, and nothing merely referenced survives the trip.

Extract pages from a PDF with software you already have

Every machine in front of you can already do this, and for one off jobs it is often quicker than uploading anything.

In Chrome or Edge, open the PDF, press Ctrl and P, set the destination to Save as PDF, then set Pages to Custom and type 3-7. On a Mac the same trick lives in Preview: File, Print, then the PDF dropdown at the bottom left and Save as PDF. Preview also lets you select thumbnails in the sidebar and drag them straight to the desktop, which creates a new PDF from the selection.

The catch is that printing re-renders the document. Text stays selectable, so this is not the same as turning it into an image, but links go flat, bookmarks are gone and form fields stop being fields. That is a loss for most jobs and a feature for exactly one: when you want a clean file carrying nothing but the pages you chose.

Extract pages from a PDF from the command line

If this is a weekly job on new files, stop clicking. Two free tools, both scriptable, both far more expressive than any page range box.

qpdf keeps the document structure intact rather than reprinting it:

qpdf input.pdf --pages input.pdf 1-5 -- output.pdf

The syntax earns its keep once you learn four symbols. z means the last page and r1 means the same thing counting backwards, so r3-r1 is the final three pages of a file whose length you do not know. A range can carry :even or :odd. And from version 11.7.1 an x prefix subtracts:

qpdf input.pdf --pages input.pdf r3-r1 -- last-three.pdf
qpdf input.pdf --pages input.pdf 5-20:even -- evens.pdf
qpdf input.pdf --pages input.pdf 1-10,x3-4 -- most.pdf

Descending ranges work, so z-1 reverses the whole document, and a list like 1,6,4 comes out in that order rather than sorted. That is the reordering the web form cannot do.

pdftk is the older option and reads more like English:

pdftk in.pdf cat 3-7 output out.pdf
pdftk in.pdf cat 1-20~5-6 output out.pdf
pdftk in.pdf cat end-1 output out.pdf

It has an end keyword for the last page, the tilde subtracts a range from another, and putting the higher number first reverses the order.

Which method fits which job

One habit is worth more than all of the above: after any extract, open the file and count the pages. Not skim it, count it. Every quiet failure in this article ends with a file that opens fine and has the wrong number of pages in it, and that is a five second check standing between you and sending a contract with the signature page missing.