To extract pages from PDF multiple files at once, run the same browser-based workflow file after file with Extract PDF Pages — the bytes are read locally and never uploaded, so handling ten, fifty, or a hundred sources still keeps the entire job on your device. The tool accepts one PDF of up to 50 MiB and up to 500 pages, lets you name pages or ranges in the exact output order, removes duplicate selections deterministically, and gives you a fresh downloadable file. Because each job takes a single source, "multiple files at once" in practice means a tight per-file loop rather than a batch uploader: pick a file, type the selection, download the result, and move on to the next PDF. That repetition is the only honest way to handle several sources while preserving the no-upload, deterministic-output benefits of the tool. Everything below explains how to keep that loop fast, how to read the page expression correctly, and which PDF features survive when a page object is copied into a new document.
What "multiple files at once" actually means in a browser workflow
A true batch extractor would accept a folder of PDFs, run the same page expression across every file, and emit one output per source in a single click. Extract PDF Pages is built around stricter guarantees — local processing, no upload, deterministic byte handling — that shape it into a single-file job. In return, processing several PDFs is a sequence of the same three steps repeated for each source: pick a PDF, type the page expression, download the new file.
This pattern holds up well for the kinds of jobs people actually run. Pulling chapters two and five out of three reports becomes three visits to the page, each with a page expression like 2, 5. Harvesting the bibliography and appendix from a stack of academic articles works the same way. The work scales linearly with file count, but the cost per file is low, no tab refresh is needed unless you want to clear the selection, and the entire pipeline stays on-device, which is the property most users actually care about when the PDFs contain drafts, client work, or internal memos.
If you specifically want to fold extracted outputs back into a single combined PDF after running the loop, the extracted files are already in the correct format for Merge PDF, which joins several local PDFs into one in the order you choose.
Page-selection syntax and ordering rules
The page expression field is the part that catches most first-time users. Tokens are separated by commas or whitespace, each token is either a single one-based page number or an inclusive ascending range written as start-end, and the tool processes tokens in left-to-right order to determine the output order. Page numbers match what a normal PDF viewer shows on the page itself, not a zero-based count.
Here are the concrete patterns the parser accepts and how each one resolves:
| Expression | Meaning | Notes |
|---|---|---|
| 5 | Page 5 only. | Single token, single output page. |
| 1, 3, 7 | Pages 1, 3, and 7 in that order. | Comma- or whitespace-separated singletons. |
| 1-3 | Pages 1, 2, and 3. | Inclusive ascending range. |
| 3-1 | Rejected. | Descending ranges are not silently reversed. |
| 5, 2-3 | Page 5, then page 2, then page 3. | Token order sets output order. |
| 3, 1-3 | Page 3, then page 1, then page 2. | Second occurrence of 3 is dropped. |
| 1.5 | Rejected. | Decimal values are not accepted. |
| -2 | Rejected. | Negative values are not accepted. |
| 1, 999 | Rejected. | Pages outside the loaded document error out. |
The duplicate-handling rule is the easiest place to lose pages without realizing it. The first occurrence wins, later occurrences are dropped, and the result reports which page numbers were de-duplicated. For a 10-page source, the expression 1, 3-5, 5, 8, 9-10 expands to: page 1, page 3, page 4, page 5, page 8, page 9, page 10 — seven unique output pages in that exact order, with the second 5 noted as a duplicate. If you actually need the same page twice in one output, that is a reordering or duplication workflow designed for that purpose rather than extraction.
Extract pages from several PDFs in sequence
For each PDF in your stack, run the following sequence. The tool is deliberately the same every time so the muscle memory transfers across files.
- Open Extract PDF Pages and click the file picker. Choose an unencrypted local PDF that is no larger than 50 MiB and contains no more than 500 pages — files outside that boundary are rejected, not shortened.
- Type the page expression into the selection field, using one-based page numbers and inclusive ascending ranges such as 5, 1-3. Token order sets output order, and duplicate pages keep only their first occurrence.
- Click extract. The browser parses the expression with the same strict parser used in production tests, copies the unique selected page objects into a fresh PDFDocument via pdf-lib, and exposes the result as a temporary local object URL.
- Read the duplicate-page notice if one appears, confirm the output page count matches the unique page count you expected, and click download to save the new file.
- Open the downloaded PDF in the viewer you actually plan to use, confirm the order and appearance, test any required links or fields, and keep the original source as the reference.
- Pick the next source file. The page is reset when a new file is chosen, but you can also adjust the expression and re-extract from the same source to try alternative selections — every new run replaces the previous result.
Repetition is the cost of staying local. For a stack of similar reports with a consistent page layout, the same expression can be reused on every file without retyping, which is the closest the per-file workflow gets to true batch handling.
Hard limits: 50 MiB and 500 pages
The contract specifies two hard input boundaries and a hard input-character boundary on the expression itself. A file at the boundary is accepted; a file past the boundary is rejected with an explicit error and is not truncated, recompressed, or partly applied.
The byte boundary is 50 MiB, equivalent to 52,428,800 bytes. The page boundary is 500 pages. The two boundaries are checked independently, so a small file with a 600-page document still fails on the page boundary even though it is well under the size cap. The selection field itself caps at 4,000 characters, which matters most when the expression contains many small ranges rather than one large range.
Output size is not capped the same way. Copying one page out of an image-heavy report can still pull in the fonts and image streams that page needs, so the resulting file can be larger than naive page-count math suggests. If the output looks surprisingly big for the number of pages you selected, the result is still valid; rerun the job with a smaller selection to isolate which page contributes the most weight.
What survives extraction and what does not
Each selected page is copied as a page object, which means the things that live inside a single page survive intact: drawn graphics, ordinary page resources such as fonts and embedded images for that page, a 90-degree rotation flag, and the crop or media box dimensions. Extraction does not rasterize pages into screenshots, so vector content stays vector and the file stays small relative to a page-by-page image export. The build pipeline runs a real integration test that constructs source pages with different sizes and identifiers, runs them through the production extractor, saves the result, reopens it, and verifies page count, output order, dimensions, and page identity — catching bugs where the right count of pages is returned but the wrong pages or a sorted order ship out.
What does not survive is anything that depends on document-wide relationships. Cross-page links, document outlines, bookmarks, page labels, layered content, embedded files as a whole, scripts, AcroForm fields that reference shared resources outside the selected pages, and cross-page destinations can all reference objects that were not copied. Digital signatures will not validate against a new PDF, so do not treat an extracted file as signed even when the source carried a valid signature. Dynamic XFA forms are not a supported preservation target in pdf-lib, and password-protected files are never opened by bypassing encryption — encrypted files are not opened by bypassing encryption, and a damaged or unsupported file fails to load outright.
Before depending on the output, open it in your target viewer and confirm any links, form fields, or signatures you need. Retain the original source. If a workflow depends on surviving signatures, XFA, accessibility structure, portfolios, attachments, or regulated archival conformance, use a specialist PDF editor instead of an extraction tool.
After extraction: combine, reorder, or trim the outputs
Once every PDF in your stack has produced its extracted file, the natural next step is to fold the per-file results into one deliverable. Merge PDF joins those local outputs into a single PDF in the order you choose, again staying in the browser. If a particular extracted file ends up with extra pages you did not want, the trimmed-page workflow lets you drop named pages and download the rest of that file locally without rebuilding anything else, also entirely in the browser.
Across all of these follow-up tools the same no-upload, no-signup, deterministic-output pattern holds, so the per-file extract loop composes into a larger local pipeline cleanly. The mental model stays the same throughout: each tool takes one or more local PDFs, applies a tight rule, and hands back a fresh local file. Repeating that pattern across many sources is how "multiple files at once" gets done in a privacy-sensitive browser workflow.