Extracting pages from a PDF offline is possible by running the extraction entirely inside your browser tab using a tool that never sends the file to a server. With Extract PDF Pages, the browser reads the original PDF bytes, pdf-lib copies the requested page objects into a fresh document, and the result is exposed as a temporary local Object URL that you save yourself. Because nothing is uploaded, the workflow behaves like a desktop utility: open the page, pick the file, type the pages you want, and download the new PDF. The tool accepts unencrypted PDFs up to 50 MiB (52,428,800 bytes) containing no more than 500 pages, enforces one-based page numbers with inclusive ascending ranges, and rejects malformed input with an explicit error rather than guessing. Token order in the page expression becomes the output order, so 5, 1-3 produces a PDF that begins with original page 5 followed by pages 1, 2, and 3. Repeated selections follow a deliberate first-occurrence rule: the second mention of a page is ignored and reported, so accidental overlaps do not silently bloat the result.
What "Offline" Means for a PDF Page Extractor
For a PDF page extractor, offline means the bytes of your source file stay on your machine the entire time. The browser tab is the only environment that touches them. Extract PDF Pages validates the file's MIME type or extension and the 50 MiB byte limit in the browser, then hands the bytes to pdf-lib, which loads the source without ignoreEncryption. Parsing the page expression, copying the requested page objects into a fresh PDFDocument, saving it, and exposing the new bytes through a temporary local Object URL all happen in the same tab. The source file, the page expression, and the resulting PDF are not uploaded to Lizely.
This matters when the document contains anything you would not share with a server: drafts, customer lists, internal memos, scanned IDs, signed contracts, or anything under a non-disclosure agreement. The local source link the page offers is also generated in the browser, so it never leaves the tab. Temporary URLs for the source and the result are released when they are replaced or when the page closes, which limits how long either blob is reachable inside the tab itself.
The File Limits an In-Browser Extractor Enforces
The offline extractor enforces two explicit local-processing limits, and a file at either boundary is accepted while anything beyond is rejected rather than shortened. Knowing the limits before you start avoids wasted attempts on oversized sources.
| Limit | Exact value | What happens at the boundary |
|---|---|---|
| File size | 50 MiB (52,428,800 bytes) | Accepted; one byte over is rejected |
| Page count | 1 to 500 pages | Accepted at the endpoints; 0 or 501+ rejected |
| Page expression length | Up to 4,000 characters | Accepted; over-length is rejected, not truncated |
| Encryption | Unencrypted only | Encrypted files fail to load; password not bypassed |
The byte limit is a clean unit conversion rather than a round marketing number. Working it out step by step: 50 MiB × 1024 KiB/MiB = 51,200 KiB, then 51,200 KiB × 1024 B/KiB = 52,428,800 bytes. That is the precise number the browser enforces. The decoded-document boundary of 500 pages is independent, so a 49 MiB file with 800 pages is rejected for page count, not size.
The output can still be large because selected page resources such as fonts and images may be copied along with the page content. File size does not scale in direct proportion to page count: extracting a single page from a resource-heavy document can keep data needed by that page. Browser memory also varies by device and tab workload, so opening other tabs can affect how much headroom the extraction has.
Page Number Syntax: What the Parser Accepts and Rejects
The page expression is parsed by the same strict routine used by the production code path, so what the field accepts is exactly what the extractor accepts. Tokens are separated by commas or any whitespace, each token is either a one-based integer or an inclusive ascending range written as start-end, and the order of tokens becomes the order of pages in the output PDF.
| Input | Result |
|---|---|
| 5 | One page: original page 5 |
| 1, 3, 8 | Three pages in this order: 1, 3, 8 |
| 1-3 | Pages 1, 2, 3 |
| 5, 2-3 | Page 5, then page 2, then page 3 |
| 3, 1-3 | Pages 3, 1, 2 (duplicate of 3 ignored, reported) |
| 5-3 | Rejected (descending range) |
| 2.5, -1, abc, 999 | Rejected (decimal, negative, malformed, out of range) |
Page numbers are one-based, matching the ordinary labels shown by PDF viewers, so you do not need to subtract one in your head. The parser preserves token order rather than sorting tokens numerically, which is how 5, 2-3 ends with page 5 first. A range like 5-3 is rejected outright instead of being silently reversed, because a reversed range is almost always a typo. The selection field also caps at 4,000 characters; over-length input is not truncated or partly applied, so a too-long expression fails cleanly rather than producing a partial surprise.
Extract Pages From a PDF Offline, Step by Step
- Choose an unencrypted PDF no larger than 50 MiB and with no more than 500 pages from your local drive.
- Enter one-based page numbers or inclusive ascending ranges in the output order you want, for example 5, 1-3.
- Run the extraction. The browser copies the unique selected pages into a fresh PDF using the parsed token order.
- Review any duplicate-page notice; the second and later occurrences of the same page are ignored on purpose, with the repeated numbers listed in the result.
- Download the new PDF from the temporary local link. The original file stays on your device and is never uploaded.
Because every step runs in the browser tab, the only network activity is loading the page itself. If you want to double-check the output, open the downloaded PDF in your target viewer, confirm the selected order and page appearance, test any links or fields you rely on, and keep the original PDF alongside the new one for reference.
Duplicate Pages, Custom Order, and What Gets Copied
The extractor follows a deliberate first-occurrence rule for repeated selections. If you type 3, 1-3, the result contains pages 3, 1, and 2 in that order, and the report flags page 3 as a duplicate. This prevents an accidental overlapping range from silently adding repeated output pages while preserving the exact order in which each page first appeared. If you intentionally need the same page twice in the output, you would need a PDF page-reordering or duplication workflow designed for that purpose, because this tool is built around unique selections.
When a page is copied, the tool copies the page object itself rather than rasterizing the page into a screenshot. A 90-degree rotation, crop box, media box, ordinary page graphics, and the resources needed to render the page all travel with the page object. The output page count equals the number of unique selected pages, and a real integration test loads the source, extracts through the production function, saves the result, reopens it, and verifies page count, output order, dimensions, and identity, so an implementation that returns the right number of pages but copies the wrong pages would fail that test.
What Stays Local and What Gets Released
Reading the original bytes, parsing the page expression, copying the selected page objects, saving the new PDF, building the local source link for comparison, and preparing the download all happen in the current browser. The source file, the page expression, and the output are not uploaded to Lizely. Changing the page expression immediately releases the previous result, and running extraction again replaces the previous output URL. Choosing another file clears the old bytes, selection, source link, result, and error. Job and mounted-state guards prevent an older asynchronous load or save from overwriting newer state, which keeps the visible result aligned with the most recent action.
Temporary source and result URLs are released when they are replaced or when the page closes, so closing the tab is the cleanest way to clear in-tab state. If you are working on a shared computer, that release path is also the easiest reason to close the tab when you are finished.
When an Offline Browser Extractor Is Not the Right Tool
Important PDF features can have relationships the selected subset cannot preserve on its own. AcroForm fields, annotations, scripts, embedded files, layers, page labels, bookmarks, document outlines, cross-page destinations, and links may depend on objects outside the pages you keep, so they may stop working in the extracted file. Digital signatures will not remain valid after a different PDF is built from the original. Password-protected or encrypted files are not opened by bypassing encryption, and damaged or unsupported files can fail to load. Dynamic XFA forms are not a supported preservation target in pdf-lib, so an XFA form is not a good candidate for this offline workflow.
If your task depends on signatures, XFA, accessibility structure, portfolios, attachments, or regulated archival conformance, use a specialist PDF editor that supports those features. For ordinary page extraction on a private document, the in-browser tool covers the common cases without sending the file anywhere. The pdf-lib PDFDocument API documents the page-copying primitives the tool relies on.