A book scanned two pages at a time, an A3 office scan that should be two A4 pages, a booklet printed two-up: all of them leave you with a PDF whose every page is really two pages. Splitting each page down the middle sounds trivial. How a tool does it decides whether you get a crisp, searchable document or a blurry, bloated one.
Two ways to cut a page in half
Rasterize and re-cut. Render each page to an image, cut the image in half, and wrap each half in a new PDF page. This is how most quick online tools and many scripts work. It costs you:
- The text layer. An OCR'd scan or a born-digital PDF loses its selectable, searchable text. You're left with pictures of words.
- Resolution decisions. Render at 150 dpi and fine print turns soft; render at 600 dpi and the file balloons.
- Vector sharpness. Line drawings, charts and type that were resolution-independent become pixels.
Re-window the page. A PDF page doesn't have to show all of its content. It has a visible window, and you can move it. Duplicate the page, point the first copy's window at the left half and the second copy's window at the right half, and you have two pages that show exactly the same original content, untouched. This is how the split.tools half-page splitter works, and it's lossless by construction.
The five page boxes
Every PDF page defines up to five rectangles, in points (1/72 inch), with the origin at the bottom-left:
| Box | Meaning | Default |
|---|---|---|
| MediaBox | The physical sheet: the full extent of the page | Required |
| CropBox | The region viewers display and print | = MediaBox |
| BleedBox | The area for print production, including bleed | = CropBox |
| TrimBox | The intended finished size after trimming | = CropBox |
| ArtBox | The meaningful content area | = CropBox |
A viewer like Acrobat, Preview or pdf.js shows the CropBox. Print workflows may look at the TrimBox or MediaBox instead, and some older software ignores the CropBox entirely. So the robust approach sets all five boxes to the half's rectangle. Then every viewer, printer and pre-press tool agrees on what each page is. The spec also requires the other boxes to sit inside the MediaBox, so shrinking only the CropBox while leaving a stale TrimBox behind invites inconsistent output.
Why the file doesn't double in size
In the PDF object model, a page's drawing instructions (its content stream) and its fonts and images are separate objects that the page references. When both halves are copied from the same source page in one operation, they reference the same content stream and the same images, and only the small page dictionaries are new. A 40 MB scanned book split into halves comes out at roughly 40 MB, not 80 MB. A rasterizing tool would produce a file whose size depends entirely on its chosen resolution.
The A-series coincidence that makes A3 → A4 perfect
ISO 216 paper sizes have a 1:√2 aspect ratio, chosen so that halving a sheet across its long side produces the next size down with the same proportions. An A3 landscape page (1190.55 × 841.89 pt) cut vertically at exactly 50% gives two 595.28 × 841.89 pt pages, which is precisely A4 portrait. US Tabloid (11 × 17 in) halves into two US Letter pages (8.5 × 11 in) the same way. For scans of real books the gutter is rarely at exactly 50%, which is why an adjustable cut line matters. More on that below.
The /Rotate trap
Here's the bug that makes some tools cut the wrong way. A page can be stored in one orientation and displayed in another: the page dictionary's /Rotate entry tells viewers to turn it 90°, 180° or 270° clockwise before showing it. Scanners and "rotate page" buttons in PDF editors set this flag instead of rewriting the page. So a page that looks landscape on screen may be a portrait page with /Rotate 90.
A tool that ignores the flag halves the stored page along its own x-axis, which on screen means cutting across the spread instead of between its two pages. The fix is to translate the visual cut into stored coordinates. For a vertical (left | right) cut:
| /Rotate | Visual cut runs across stored… | Visual left half is the stored… |
|---|---|---|
| 0 | x-axis | low-x side |
| 90 | y-axis | low-y side (bottom) |
| 180 | x-axis | high-x side |
| 270 | y-axis | high-y side (top) |
A horizontal (top / bottom) cut swaps the axes again: at /Rotate 90 the visual top is the stored low-x side. It's a small table, but getting it wrong produces output that looks like random cropping. The rule of thumb for any page tool: operate on what the reader sees, then map it back.
Real scans aren't symmetrical
- Off-centre gutters. Book scans drift: the spine sits at 48% on one page and 52% on the next. A fixed 50% cut slices letters at the inner margin. An adjustable cut line (split.tools steps it in 0.5% increments) lets you place the cut in the empty gutter. It still applies one position to every page, so badly inconsistent scans may need two passes over different page ranges.
- Covers. Front and back covers are often scanned as single portrait pages among landscape spreads. Splitting a cover in half is wrong, so the tool can skip portrait pages automatically, or keep the first and last pages whole.
- Reading direction. For manga and for Arabic, Hebrew and Persian books, the right half comes first. A right-to-left option swaps the order of each pair.
- Skew and curvature. A spread photographed at an angle, or with a curved spine, can't be fixed by straight cuts. For that level of clean-up, ScanTailor Advanced (open source) deskews, dewarps and splits scanned pages in one workflow.
Booklets are a different problem
A saddle-stitched booklet printed two-up is imposed: the sheet carrying page 1 also carries the last page, so the order of the halves after splitting is something like 8, 1, 2, 7, 6, 3, 4, 5 for an 8-page booklet. Halving the pages is still correct, but you'll need to reorder the result afterwards. Picking pages in order with the main PDF splitter does that.
The privacy catch: cropping isn't deleting
Re-windowing is lossless because it keeps everything. The left-half page still contains the full content stream, including the right half's text and images, just outside its window. Consequences:
- Anyone with a PDF editor can enlarge the box and see the hidden half.
- Some text-extraction tools ignore page boxes, so copying or searching a page's text may surface words from the half you can't see.
For splitting a scanned book, that's harmless. For splitting a document so that one half can be shared and the other kept private, it's a leak. In that case, print each half to a new PDF ("Microsoft Print to PDF" or macOS "Save as PDF"), which re-renders only the visible content, or use a real redaction tool that removes the underlying objects.
Checking the result
- Page count. The output should have the original count plus the number of pages you cut. split.tools shows this before you download.
- Select some text on a cut page. If it highlights, the text layer survived. With a rasterizing tool it wouldn't.
- Zoom to 400% on fine print. A box-cropped page stays sharp; a re-rendered one shows pixels.
- Look at the inner margin of a few pages for clipped letters. If you see any, nudge the cut line and run it again. Iterating is free when nothing has to be uploaded.
Split your PDF pages in half in the browser: the preview shows the cut line on your own page, and the document never leaves your device.