Split PDF Pages — Extract & Separate PDF Files Online

A multi-page scan needs to be laid out one sheet per file, a couple of sections have to come out of a general report, a bulky contract has to be broken into appendices. The "Split" tool in pdfredX cuts the document right in the gallery: scissors appear between the pages, you place cuts where you need them and download each part as a separate PDF. All in the browser, nothing uploaded to a server.

Step 01. Load the PDF

Open pdfredx.com and drag a multi-page PDF into the drop area — or pick it through your file browser. PDF.js renders the pages inside the tab, and each becomes a card in the gallery. Not a single byte goes to a remote machine.

Step 02. Place the cuts

Turn on "Split" mode — slots with a ✂️ icon appear between adjacent cards. A click on a slot places a divider: the document will split into two parts at that point. You can place as many cuts as you like — that is how any number of parts is defined.

• Break into individual pages — place a cut after every card: each part becomes a one-page file.
• Extract a section — place two cuts, at the edges of the range you need; the middle part is your fragment.
• Remove an unwanted cut — press ✕ on the divider, and the parts merge back together.

The cuts are virtual: they don't touch the source pages, they only show how the document will be divided. Made a mistake — remove the divider, nothing is lost.

Step 03. Download the parts

A panel with the list of parts opens at the bottom. For each one you see the page range and their count, and next to it — a file name field (by default split_part_1, split_part_2, …) and a "⬇ Download" button. Give them clear names and download the parts you need one by one — or press "Download all" and get every part in sequence. The finished PDFs are saved straight from the browser. Free, no registration, no server queue.

How it works under the hood

Splitting doesn't reassemble the document on disk — it works over the items[] array of pages that the app built at load time. The dividers are stored as a set of positions, splitGalleryDividers; the buildSgParts() function cuts continuous ranges along them:

for (const cut of cuts) {          // cuts — sorted divider positions
  parts.push({ from: start, to: cut, indices: sgRange(start, cut) });
  start = cut + 1;
}

When a part is downloaded, downloadSgPart() builds a new file through jsPDF: it takes only the pages of its range, fits each into an A4 sheet with proportions preserved (contain) and centers it. The source document is not changed in the process — you can adjust the cuts and download parts in any order.

Known limitations

The result is raster. Pages are inserted into the parts as images. In the resulting PDFs the text cannot be selected or copied — it is part of the picture. Hyperlinks, bookmarks and form fields of the source are not carried into the parts.

Cuts only between pages. The tool divides the document along page boundaries (a whole page goes into one part or another). Cutting a page itself in half is a different task — there is a separate tool for spreads.

Part order follows the document. Parts come in the same order as the pages. If you need to rearrange sheets first, do it in the gallery before splitting.

Need the opposite — combine several files into one? That is the Merge PDF tool. And to cut book spreads in half — Split Spread.

Try it right now — pdfredx.com, no registration, your files stay with you.

You need to send the accountant one page out of a 30-sheet contract. From a bundle of scans — forward only the certificate, without showing the rest. From a statement — keep a single spread. All of these tasks share one meaning: share a part, not the whole. And here an ordinary online PDF-splitting service offers exactly the opposite — upload the entire document to its server in order to cut a couple of pages out of it. Let's look at why that contradicts the very goal, and how to do it differently.

The paradox of server-side splitting

You split a PDF precisely because you don't want to show the document in full. Yet to "extract page 7," an ordinary service asks you to send all 30 sheets. That is, for the sake of isolating one page, you expose the entire rest of the contract to an outside service — the very data you meant to keep to yourself.

From there the uploaded file lives by the service's policy, which few people ever read:

• the document is stored in a contractor's temporary storage (AWS, GCP, Azure);
• it is processed on someone else's server;
• it is kept from a few hours to several days "for reliability";
• it is logged together with metadata — IP, time, file name and size.

For confidential bundles — contracts, HR packages, medical or banking scans — that is exactly the risk you were trying to sidestep when you decided to send a single page rather than the whole document.

Local splitting: the document never leaves the tab

pdfredX cuts a PDF without uploading it anywhere. That is a consequence of the architecture, and you can verify it.

The file is read locally. PDF.js opens the document in the tab and draws the pages to a Canvas. There is no network request carrying your file.

Cuts and assembly happen in the tab's memory. You visually place dividers between the pages, and the parts you want are assembled into new PDFs through jsPDF — all of these are operations on data that is already loaded. Nothing is sent anywhere.

You download only what you selected. Want one page — a one-page file is assembled and downloaded. The other sheets go nowhere: they stay as images in the tab's memory and disappear when you close it.

It works offline. Load the document, turn off the internet and extract the pages you need — everything keeps working. The network is only needed to load the app once.

In practice: turn on "Split" mode, place cuts at the edges of the fragment you need, give the file a clear name and download only that part. Everything else stays with you.

What we cannot guarantee — an honest disclaimer

Client-side processing protects a document from being sent to external servers, but it is not a shield against every threat, and promising otherwise would be dishonest.

Malware or a keylogger on the device. If the machine is compromised, a program can read files off the disk bypassing the browser entirely.

Browser extensions with broad permissions. An extension with "read data on all sites" access can, in theory, see the tab's contents. For sensitive documents, work in a profile without third-party extensions or in a private window.

The saved parts stay on your disk. If the device is not protected by encryption, files can be read by third parties with physical access.

We provide isolation at the level of the browser tab. The rest is on the user's side.

Extract the pages you need without uploading the whole document to a server — pdfredx.com, free, no registration.

You can split a PDF "by the book" on a server: parse the structure, pull the needed page objects at the binary-graph level (Objects and Streams), assemble new containers from them without re-rendering — preserving text and hyperlinks. In the browser, with no backend and no file upload, the set of constraints is different, and the architectural choice is not obvious. Let's break down how the split tool in pdfredX is built: why splitting works over a raster array of pages, how the cuts stay non-destructive, and where the boundaries of the approach run.

The architectural challenge: parsing structure vs. the raster pipeline

How PDFs are split "by the book." Libraries like pdf-lib can extract pages at the structure level: they find the page objects in the tree, copy them together with their resources (fonts, images, annotations) into a new document without rasterizing. That preserves the text layer and hyperlinks. The price is complexity: it needs a full PDF parser and careful work with the binary graph, and on files with non-standard metadata or a corrupted xref the stability drops.

Why pdfredX takes the raster path. The tool is built into the app's shared pipeline, where a page of any document is already reduced to an image: PDF.js drew it to a Canvas at load time and put it into the items[] array. So splitting does not re-parse the structure — it operates on ready-made rasters. The upsides are predictability (if PDF.js showed a page, it can be moved into a part) and privacy (cutting and assembly happen in the tab, the file goes nowhere). The price is a raster result: the text layer and hyperlinks are not preserved in the parts. For the typical scenario (lay out scans, extract a section) that is a justified trade-off.

The implementation, piece by piece

Cuts as a set of positions

The user places dividers between the cards. Each cut is simply a position in the array, added to a Set:

function toggleSgCut(afterIdx) {
  if (splitGalleryDividers.has(afterIdx)) splitGalleryDividers.delete(afterIdx);
  else                                    splitGalleryDividers.add(afterIdx);
  render(); renderSgPanel();
}

This is the key decision: a cut does not slice the data, it only marks a boundary. The source items[] is not mutated, so the cuts are fully reversible — remove a divider and the parts merge again. No intermediate copies of pages in memory.

Cutting into continuous parts

From the sorted set of positions, buildSgParts() assembles continuous ranges of pages:

const cuts = Array.from(splitGalleryDividers).sort((a, b) => a - b);
let start = 0;
for (const cut of cuts) {
  const end = Math.min(cut, items.length - 1);
  parts.push({ from: start, to: end, indices: sgRange(start, end) }); // range of indices
  start = cut + 1;
}
if (start <= items.length - 1) parts.push({ from: start, to: items.length - 1, ... }); // the "tail"

Each part is a description of a range (from, to) and a list of page indices. Nothing is copied until the user presses "Download": the panel simply shows which pages will go into which file.

Assembling a part: jsPDF over the indices

Only on download does downloadSgPart() materialize a part into a real PDF — the same way as merging and compression: it takes the pages of its range, fits each into an A4 sheet with proportions preserved (contain) and centers it.

for (let i = 0; i < part.indices.length; i++) {
  const p = items[part.indices[i]];
  const dim = await imgDims(p.editUrl);
  if (i > 0) pdf.addPage('a4', dim.w > dim.h ? 'landscape' : 'portrait');
  // ...contain + centering...
  const fmt = p.editUrl.startsWith('data:image/png') ? 'PNG' : 'JPEG';
  pdf.addImage(p.editUrl, fmt, x, y, dw, dh, '', 'FAST');
}
pdf.save(fileName); // name from the part's input field

Each part gets its own name from the input field; "Download all" just calls downloadSgPart() in turn with a tick(600) pause between files, so the browser has time to serve the downloads.

Trade-offs and the limits of the approach

Text and hyperlinks are not preserved. This is a direct consequence of the raster path: a page in a part is an image. Where live text is critical (legal documents for further editing), structural extraction would be more precise.

Division only along page boundaries. A cut is placed between cards; cutting a page itself in half is a job for another tool (spreads).

Memory on large documents. All pages live in items[] as decoded images (an A4 sheet at 150 DPI is ~8.7 MB RGBA). On hundreds of pages that is noticeable, but the splitting itself is light: the cuts are a set of numbers, and only the part being downloaded is materialized into memory.

What's next

Optional structural extraction for purely digital PDFs — a separate branch through object parsing, to preserve text and links when the source allows it.

Exporting parts to ZIP — pack all the parts into a single archive instead of sequential downloads, more convenient with a large number of parts.

Want to test it on your own document — load a multi-page PDF on pdfredx.com, place the cuts and download the parts. No registration, no file upload to a server.