Choose the pages you want and save them as a separate document, without the original leaving your machine. This extracts a selection into one new file rather than bursting a document into dozens of them.
Runs in your browser. Nothing is uploaded.
Ask for pages 1 to 10 and this builds an empty document, lifts those ten page objects out of the original along with the resources each one depends on. The fonts it references, the images it draws, the colour spaces it uses, and writes them into the new file with a rebuilt index. The pages you did not ask for are never opened, and neither is the text on the pages you did. It is a copy operation on the file's object graph, which is why ten pages come out in twenty milliseconds.
The consequence worth understanding is that the output size tracks what you keep rather than what you discard, and not always in a straight line. Taking ten pages out of a forty-page text report produced a file 25.4% of the original, almost exactly the proportion of pages kept. Taking ten of twelve pages from a scan produced 89.7% of the original, because every page of a scan carries its own full-page image and those images are the file. A page of dense text weighs almost nothing; a page that is a photograph weighs a megabyte. Which pages you pick matters more than how many.
Choose a PDF
The same questions a security review would ask, answered plainly.
The parts that matter when the document is confidential or large.
Type something like 1-3, 7, 12-15 in one go. Hyphens give you a span, commas separate selections, and the two mix freely in a single expression.
The document is opened as soon as you pick it and its length is shown, so you can write a range against a real number instead of guessing and checking.
Extraction reads the file you chose and writes a new one. The document on your disk is untouched, so there is nothing to undo if the range was wrong.
Ten pages out of a 10 MB scanned document took 35 milliseconds. Nothing is rendered or recompressed, so size affects the result far less than you would expect.
There is no upload step and no server to receive one. The page loads once, then all work on your PDFs happens in local JavaScript.
No daily limits, no per-file ceilings imposed by a server tier, no watermarks, and no account. The practical limit is your own device's memory.
The same range against very different documents, and why the results diverge.
The everyday case: one chapter out of something much longer.
Source
40-page A4 report, 165,897 bytes
Pages 1-10
42,181 bytes, 20 ms
Settings: Range: 1-10
A quarter of the pages produced just over a quarter of the bytes. Text pages are roughly interchangeable in weight, so for a document like this the size of the result is a good proxy for how much of it you kept.
Dropping a couple of pages from a scan barely helps.
Source
12-page scan, 10,324,119 bytes
Pages 1-10
9,258,693 bytes, 35 ms
Settings: Range: 1-10
Removing two of twelve pages removed a tenth of the file. Each scanned page is a full-page image and those images are almost the entire document, so the only way to make a scan meaningfully smaller is to drop a lot of pages or to re-encode the images.
Real files, real numbers, and the machine they were run on.
| Scenario | Input | Output | Time | Notes |
|---|---|---|---|---|
| pages 1-10 of the 40-page text PDF | 165,897 bytes | 42,181 bytes | 20 ms | 25% of pages, 25.4% of bytes |
| pages 1-10 of the 12-page scan | 10,324,119 bytes | 9,258,693 bytes | 35 ms | 83% of pages, 89.7% of bytes |
How this was measured: Measured by driving this page in headless Chrome 152 on an Apple M4 Pro running macOS 15.5, on 2026-09-17. The fixture is handed to the page's own file input, the page's own button is pressed, and the figure recorded is the size of the file the page produces. Timings come from a warm page on a fast machine with no network involved, so treat them as a floor rather than a typical result.
A thirty-page lease where the other party needs the schedule on pages 22 to 26. Extracting locally means the clauses you did not intend to share are not sitting on someone else's server as a side effect.
Lifting one chapter out of a large textbook or standard so it opens quickly on a tablet and can be annotated without scrolling past everything else.
Board packs, patient files and case bundles frequently need one section forwarding. These are the documents where an upload step is the thing that makes the task a policy question instead of a two-minute job.
When a document is too large to send, removing the pages the recipient does not need is often quicker than compressing, and unlike compression it costs nothing in quality.
Producing a file that contains exactly the pages to be printed avoids the perennial error of leaving a print dialog set to a range from the last job.
A stack of separate documents scanned in one pass arrives as a single PDF. Running the tool once per document turns it back into the individual files it should have been.
Boundaries of the operation itself, stated so you find them here rather than afterwards.
Everything you select lands in a single document. There is no mode that bursts a 50-page PDF into 50 separate files; to produce several documents, run the extraction once for each range you need.
The selection is treated as a set of page numbers, sorted before extraction. Asking for 9, 2 gives you page 2 followed by page 9, and asking for the same page twice gives it to you once. Extraction cannot be used to reorder or duplicate.
Pages are copied into a new document, and anything held at document level rather than page level is left behind. A fillable field keeps its appearance but stops accepting input, and the outline tree disappears. Worth checking before forwarding an extract of a form.
Ask for 1-999 on a 12-page file and you get all 12 pages with no warning; a range that matches nothing at all is rejected as invalid. The page count shown beside the filename is there so you can avoid guessing.
Yes, in two ways. Watch the Network panel in your browser's developer tools while you extract, after this page's own files load, nothing further is requested. Or take the machine off the network completely once the page is open and extract anyway; it works, which is impossible for anything that relies on a server.
Whole numbers and hyphenated spans, separated by commas. 1-3, 7, 12-15 means pages one to three, page seven, and pages twelve to fifteen. Spaces around the commas are fine. Open-ended forms such as 5- are not understood; give the last page number explicitly.
Not in one action. The extraction produces a single document from whatever you select, so to end up with separate files you run it once per page or per range. For a handful of pages this is quick; for a hundred it is the wrong tool.
Page 2 first, then page 9. The range is collected into a set and sorted ascending before anything is copied, so the original sequence is always preserved and the order you typed is not meaningful.
No. The image objects on the pages you keep are copied across unchanged, at their original resolution and with their original compression. A 300 dpi scan extracted from a larger document is byte-for-byte the same scan.
Because size in a scanned PDF lives in the page images, and you kept most of them. Ten pages out of twelve came back at 89.7% of the original file. Dropping pages only helps in proportion to the weight of the pages dropped.
Select everything except the pages you want gone. To remove page 5 from a 20-page document, extract 1-4, 6-20. The result is the document minus that page, which is the same outcome by a different route.
Never. The file you choose is opened read-only in the browser and a separate document is written for download. Whatever is on your disk is exactly as it was, so a mistaken range costs you a download rather than your source.
Not while the file still demands a password. The page tree cannot be read, so the ranges you type have nothing to copy. Clear it via the unlock tool, then extract from the download it writes. The locked original stays put on disk.
Nothing is capped here, because no server is involved to apply a cap. The constraint is memory: the source document is held in the tab while the new one is built, so very large files behave better on a laptop than on a phone.
Annotations attached to the pages themselves are copied with them. A link that points to a page you did not extract will survive as an annotation with nothing to jump to, because its destination is no longer in the document.
Yes, after the first load. All the code needed to open a document and write a new one is already sitting in the browser by then, so pulling the network cable changes nothing. Only a fresh reload needs the page to still be cached.
There is no limit imposed by us, because there is no server tier to enforce one. The real constraint is your device's available memory, since the whole file is held in RAM while it is processed. Very large files are slower on phones than on a laptop.
No. There is no sign-up, no email, and no usage tracking tied to an identity. The tool works the first time you open it.