Split PDF Book Spread — Cut Scanned Pages in Half Online

When you scan a book, a magazine, or an old file, each sheet holds two pages side by side — a spread, or a double page. To get a normal page-by-page PDF, every spread has to be cut down the middle. No retyping, no round-trips through an online service: the Split Book Spread tool in pdfredX cuts pages right in your browser, and the file never leaves your device.

Step 01. Load the Scan

Open pdfredX and drag a PDF or spread photos into the upload zone. Multi-page PDFs and images (JPEG, PNG, HEIC, WebP) are all accepted. Each spread shows up in the gallery as its own card.

The file is read locally through FileReader and rendered to Canvas — not a single byte goes to a server. Speed depends on file size and device: a light scan opens instantly, a heavy 200+ page one on an old phone takes a few seconds.

Step 02. Choose the Cut Direction

Click Split Book Spread in the main menu or toolbar — the #SS panel opens. Pick how to cut:

• Vertical — a cut down the middle from left to right: left page + right page. This is the ordinary book spread.
• Horizontal — a cut down the middle top to bottom: top half + bottom half. This is how it looks when the sheet was scanned sideways (a landscape spread on a portrait scanner bed).

The cut always runs exactly through the center of the sheet. If the book's spine drifted off-center, straighten the frame with the crop tool first, then cut.

Step 03. For a Horizontal Cut — Set the Rotation

A horizontal cut almost always means the halves need turning to the right orientation. In the panel, pick the direction: ↻ +90° or ↺ −90°. The app rotates both halves through the rotCanvas() function (the same rotation engine as the crop editor). A vertical cut needs no rotation — the halves already sit the right way up.

Step 04. Apply and Save

Click Apply. A purple progress overlay (#OV) appears during processing: the app walks through every spread in a single pass and replaces each page with two new ones. A 50-sheet book becomes 100 separate pages, order preserved.

The result shows in the gallery immediately. Click Create PDF — all pages are assembled into one file via jsPDF and downloaded straight from the browser. Free, no sign-up, no waiting on a server queue.

How It Works Under the Hood

At the core is the Canvas 2D API method drawImage(img, sx, sy, sw, sh, dx, dy, dw, dh). The first four numbers define a crop rectangle from the source scan, the second four define where and at what size to place it on a new canvas. The left half takes the crop (0, 0, width/2, height), the right half (width/2, 0, width/2, height). Each half is drawn onto its own canvas and becomes a new page image.

The page array items[] is processed in one pass: the single spread element is replaced in place by two page elements. Nothing re-renders the whole document — only pixel cropping — so even a thick book splits in seconds.

Known Limitations

The cut is strictly centered. If the spread was scanned asymmetrically (spine off-center, uneven margins), the halves come out uneven. Straighten the frame with the crop tool before cutting.

Curved spines. On thick books, text near the spine "sinks" and slants. A geometric center cut won't fix that — it divides the sheet, it doesn't flatten the page.

Rasterized output. Pages are cut as images, not as vector text. If the source had a selectable text layer, it becomes part of the image after cutting. To bring the text layer back, run the Area OCR tool on the relevant pages.

Memory on large scans. A book of 300+ spreads means 600+ page images in RAM. Low-end phones may pause; on desktop it's barely noticeable.

If you don't have a book spread but a duplex scan from two ADF passes (front sides separately, back sides separately), that's a different job — use the Duplex Scan Assembler instead.

Try it now — pdfredx.com, no sign-up, your file stays with you.

You've scanned a book, an archive file, or a stack of contracts — and you're left with a multi-page PDF where every sheet holds two pages. To split it into single pages, you open the first online service in the results, hit Upload, and run into one of three walls: a file-size limit, a slow upload, or a question few people ask — where did your document actually go?

Let's look at both paths honestly.

Why Server-Side Splitters Are a Poor Fit for Book Scans

File-size limits. A 200–400 page book scan is tens, sometimes hundreds of megabytes. Free server-side services almost always cap files: "up to 10 MB," "up to 50 MB," "upgrade for larger files." A heavy archive scan simply doesn't fit.

Slow round-trips. Even when the limit allows it, the file first travels to the server in full, gets processed there, then comes back down. On a slow or mobile connection that's minutes of waiting — for an operation that boils down to cropping images.

The document lands on someone else's machine. Book scans are often not novels but archive files, medical records, accounting binders, litigation material. When such a file goes to a server, it:

• gets written to a contractor's temporary storage (AWS, GCP, Azure);
• may be retained anywhere from hours to days "for reliability";
• is logged along with metadata — IP, timestamp, file name and size;
• may, under some services' terms, be used "to improve the product."

Retention periods live in the fine print of a privacy policy. You can't verify the file was actually deleted — you can only trust.

Full Browser Isolation: How pdfredX Cuts a Spread

pdfredX lets you split a PDF into pieces with no server — the file is never uploaded. This isn't a line from an "About Us" page; it's a property of the architecture you can verify.

The file is read locally. PDF.js 3.11.174 opens the document inside the tab through FileReader and draws pages to Canvas. There's no network request carrying your file.

The cut happens in the tab's memory. Cropping the halves is a Canvas 2D drawImage over the pixels of an already-loaded image. All computation is local.

No size caps from us. The only limit is your device's memory, not a service's pricing tier. A thick scan cuts the same as a thin one.

PDF assembly on the client. The finished pages are composed by jsPDF inside the tab and handed to the browser for download. The file goes to your Downloads folder — not to a server and back.

Works offline. Want to confirm the isolation? Open the tool, disconnect from the internet, and cut a scan. Everything keeps working: the network is only needed to load the app itself once.

Step by Step, With No Server Upload

01. Load the scan. Drag the PDF of spreads into the upload zone at pdfredx.com. FileReader reads the file locally — it never leaves the device.

02. Choose a direction and cut. Open Split Book Spread, set a vertical or horizontal cut (for horizontal, the rotation direction). Click Apply — each page is replaced by two halves in the tab's memory.

03. Save and close. Click Create PDF — jsPDF assembles the document locally and hands it over for download. Once you close the tab, the file data is gone: nothing persists in sessionStorage or in memory.

What We Cannot Guarantee — An Honest Disclaimer

Client-side processing protects the document from being sent to external servers, but it isn't a shield against every threat, and claiming otherwise would be dishonest.

Malware or a keylogger already on your device. If the machine is compromised, software can read files from disk outside the browser. A web app has no say over that.

Browser extensions with broad permissions. An extension with "read data on all sites" access can, in theory, see tab content. For sensitive scans, work in a profile with no third-party extensions or in a private window.

The saved file stays on your disk. If the device isn't protected by encryption, confidential files can be read by third parties with physical access.

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

Cut book scans with no server upload and no size limits — pdfredx.com, free, no registration.

The task sounds simple: take a sheet with two pages and cut it in half. In practice all the engineering lives in the details — how to crop pixels without quality loss, how to rotate the halves on a horizontal cut, how to turn one element of the page array into two without breaking order, and where the browser runs out of memory. Here's how the split-spread tool in pdfredX is built — no server, entirely on the Canvas 2D API.

The Architectural Challenge and Stack Choice

Splitting a page on a server is trivial: receive the file, parse the PDF structure, slice through a library, return the result. In the browser the constraints are different.

Why Canvas, not PDF-structure parsing. The PDF format is a complex binary graph: cross-reference tables, compressed object streams, fonts, color profiles. Shipping a full parser to the browser for a geometric "cut this in half" operation is overkill and fragile on non-standard files. Book scans are raster to begin with: each page is an image. So we work on the Canvas render, not on the document structure.

Why drawImage, not a manual pixel loop. You could copy a half via getImageData / putImageData, pixel by pixel. But the eight-argument drawImage does the same thing hardware-accelerated, in a single call, with scaling built in. For cropping it's the right tool: less code, faster, no intermediate buffers.

Why everything is local. PDF.js renders pages in the tab, jsPDF assembles the result there too. The file never goes to a server — which is both faster (no round-trip) and more private (the book scan stays on the device).

Algorithm Breakdown

Cropping the Halves With drawImage

The method signature is drawImage(img, sx, sy, sw, sh, dx, dy, dw, dh). The first quad (sx, sy, sw, sh) is a crop rectangle from the source image. The second (dx, dy, dw, dh) is where and at what size to place it on the target canvas.

For a vertical cut (left + right pages):

const w = img.naturalWidth, h = img.naturalHeight;
const halfW = Math.floor(w / 2);

// Left page: crop [0 .. halfW] across the width
const left = document.createElement('canvas');
left.width = halfW; left.height = h;
left.getContext('2d').drawImage(img, 0, 0, halfW, h, 0, 0, halfW, h);

// Right page: crop [halfW .. w]
const right = document.createElement('canvas');
right.width = w - halfW; right.height = h;
right.getContext('2d').drawImage(img, halfW, 0, w - halfW, h, 0, 0, w - halfW, h);

For a horizontal cut the same formulas apply on the Y axis: top half is the crop (0, 0, w, halfH), bottom half (0, halfH, w, h - halfH). Note the Math.floor and the w - halfW remainder: on an odd width, pixels must not be lost or duplicated, so the second half takes the "tail."

Rotation on a Horizontal Cut

A horizontal cut usually means the sheet was lying sideways — the halves need turning. Here rotCanvas() from editor.js is reused (the same rotation engine as the crop tool, built on Cropper.js 1.5.13):

if (direction === 'horizontal') {
  topHalf    = rotCanvas(topHalf, angle);     // angle = +90 or -90
  bottomHalf = rotCanvas(bottomHalf, angle);
}

rotCanvas creates a new canvas with swapped sides (height × width) and draws the source through ctx.rotate(). The angle comes from the user's choice in the #SS panel (↻ +90° / ↺ −90°) — the direction depends on how the original was turned during scanning.

Array Mapping: One Page → Two

The subtlest part is rebuilding the shared page array items[] without breaking order. Each spread is replaced by two pages in place:

const result = [];
for (const page of items) {
  const [a, b] = splitPage(page, direction, angle);   // two dataURLs
  result.push(makeItem(a, page));   // left / top
  result.push(makeItem(b, page));   // right / bottom
}
items = result;   // N spreads become 2N pages

A single linear pass. Nothing re-renders the whole document: splitPage works only on the already-rendered page image. During the pass the #OV overlay is shown (purple, z-index: 700), because for a thick book the loop still takes a noticeable fraction of a second — and the user should see that work is in progress, not a freeze.

Assembling the Result

After the mapping, items[] holds twice as many elements. The final PDF is assembled by jsPDF: a pass over the array, addImage() per page, A4 orientation derived from the half's proportions. Assembly happens entirely in the tab's memory, and the file is handed to the browser for download.

Performance and Memory Limits

Doubling the object count. A 200-spread book becomes 400 page images in memory after the cut. Each A4 page decoded into Canvas at 150 DPI is about 8–9 MB of RGBA bitmap. 400 pages is potentially several gigabytes of peak memory. Chrome caps a tab at roughly 2–4 GB and, as it approaches the limit, starts evicting inactive objects, which triggers re-renders when you scroll back through the gallery.

Why halves aren't kept at full resolution forever. Each drawImage result is immediately converted to a compressed dataURL (canvas.toDataURL('image/jpeg', quality)), and the heavy intermediate canvas is released to the garbage collector. This keeps peak memory reasonable: what lives in memory are compressed strings, not raw bitmaps of every half at once.

Where it hits the wall on mobile. On a phone with 3 GB of RAM the comfortable ceiling is around 150–200 spreads (300–400 output pages). Beyond that, expect pauses and scroll lag. On desktop the threshold is markedly higher.

The main thread. The cut currently runs on the main thread — hence the progress overlay. Moving it into a Web Worker via OffscreenCanvas would remove the UI stall on large books, but it ran into unstable Safari support at implementation time. This is acknowledged technical debt.

What We're Planning to Fix

OffscreenCanvas + Worker — move the cut off the main thread once Safari support stabilizes.

Spine-line auto-detection — the cut is currently strictly centered; detecting the real seam would let asymmetric spreads split without manual cropping.

Streaming export via WritableStream — assemble 1000+ page PDFs without the peak memory spike.

If you want to stress-test it, load a real multi-page book scan at pdfredx.com. No sign-up, no file uploads to any server.