Halve PDF pages

Halve PDF pages assumes each page is exactly half-and-half. If your spreads have asymmetric gutter offsets (one side wider than the other), the tool will still cut at the midpoint, which may clip content slightly on one side. For asymmetric splits, use Crop PDF twice: once to produce the left side, save, then crop the original to the right side and merge the two results. It is more work but gives pixel-level control. For most scanned booklets and music spreads, the midpoint cut is correct — printers and scanners produce symmetric two-up output by default. A future update may add a draggable split line for asymmetric documents; for now, the midpoint is fixed. Everything runs locally so you can iterate freely.

Each page is halved independently in the direction you chose, so a document with mixed orientations will halve every page the same way. If your file has portrait pages and landscape spreads mixed together (a body in portrait with a landscape figure section), halving with Vertical will split the landscape spreads correctly and split each portrait page in two unwanted halves. The workaround: use Split PDF first to separate the landscape section from the rest, halve only that section, then merge back with Merge PDF. Future versions may allow per-page split direction; today the choice is global per save. Most documents are uniform enough that this is not an issue in practice.

Yes. Halve PDF pages uses the PDF page's CropBox approach, similar to Crop PDF — the underlying content stream is preserved, and viewers display only each half. Text that was on the left half remains as searchable, selectable text in the new left-half page. Hyperlinks and annotations that fall on a given half stay with that half; those crossing the midpoint may end up partially on each new page, which can cause weird click behavior but does not break the underlying text. For OCR'd or natively text-based PDFs, halving produces clean output with full searchability. For image-only scans, the halves are still images, and searchable text requires running OCR PDF on the halved result.

Manga, Hebrew, Arabic, and traditional Chinese documents read right-to-left, so when scanned as two-up spreads, the right page is logically first and the left page is second. Standard halving (left first, right second) puts these in the wrong reading order. Enable Right-to-left and the tool emits right halves before left halves for each spread, producing pages that read in the correct linguistic order. This applies only to Vertical splits — horizontal stacked layouts always read top first. Music scores and many magazine layouts are left-to-right and should leave the option unchecked. If you are unsure, save once with the default and once with RTL enabled, and pick the version where pages 1 and 2 of the output read sensibly.

Split PDF divides a PDF into multiple output files based on page ranges or chunks. Halve PDF pages keeps everything in one output file but doubles the page count by cutting each page in two. They serve different needs: Split for splitting a book into chapters as separate files, Halve for un-stitching two-up spreads into a single longer document with single-page reading. The two can be chained — halve a two-up scan, then split the result into chapters. Use Halve when input pages are physically larger than the logical pages they contain (a printed booklet scanned as A3 spreads, for example), and use Split when input pages are at the correct size but you want them in separate files.

Slightly. Halving doubles the number of pages but each new page references half of one original page's content stream, so the total content data is roughly identical. There is a small overhead for the extra page objects in the file — maybe 1-3% size growth on typical documents. Embedded fonts and images are referenced rather than duplicated, so a heavy scan that was 10 MB before halving will be about 10.1-10.3 MB after. If you need to reduce size, run Compress PDF on the halved result. Files with no embedded content (vector-only PDFs) see almost no size change; image-heavy scans see negligible change because the images themselves are not duplicated, just referenced from two new page positions each.