Splitting and merging a PDF on a phone

Someone sends a 60-page PDF and you need pages 12 to 18. Or you have four scans that should be one document before you email them. Both are among the most searched file tasks there are, and both are handled by software already on your phone — no upload, no account, no watermark.

Split PDF means extracting a subset of pages into a new file, and merging is the reverse: combining several files into one, in an order you choose. Neither operation re-encodes anything. Pages are copied whole, which is why the result is instant and why quality never changes.

How do you split a PDF with nothing installed?

You do not need an app to split a PDF or to merge one. Three built-in routes cover almost every case.

On iPhone and iPad, the Files app handles both directions. To merge, select several PDFs, then choose Create PDF or use the share sheet's PDF option — the order follows the order you selected them in, which is the part people get wrong. To split, open the PDF, use the thumbnail view to select the pages you want, and share just those.

The print dialogue is the other route, and it is more reliable for page ranges. Open the document, choose Print, set the range you want, then pinch outward on the preview to turn it back into a PDF you can save. It looks like a trick and it is a supported one.

On a Mac, Preview is the tool. Open the sidebar, drag pages between two open documents to merge, or select thumbnails and drag them to the desktop to extract. Dragging a page from one PDF to another moves it rather than copying, so hold Option if you want the original untouched.

On Android, the built-in options are thinner. Files by Google and most vendor file managers will not split PDF pages for you; a dedicated app or the print-to-PDF route is usually needed.

Splitting and merging never re-encode the page content, so a merged file is roughly the sum of its parts and a split file loses nothing in quality.

What to check before you send the result

Four things to check after you split or merge a PDF, and the first one is the reason this article exists.

• Page order after merging. Selection order, not filename order, usually determines the result. A merge of scan1, scan10, scan2 sorted by name puts page 10 second.
• Orientation. A page rotated in the viewer may not be rotated in the file. Rotating in the thumbnail view and saving fixes it permanently; rotating in the viewer alone does not.
• File size. Merging four photo-based scans produces a large file, and many mail servers reject attachments above roughly 20–25 MB.
• What is still in there. A split file inherits the original's metadata, and an extracted page carries any annotation layer with it.

That last point matters when the reason for splitting is to share less than the whole. Removing pages removes the pages; it does not remove document properties, and it does not remove text hidden under a black rectangle drawn as an annotation. Redaction and covering are different operations, and only one of them removes the text.

Why did the file get so much bigger?

Because of what is inside the pages, not the merge itself.

A PDF made from text is small — a few tens of kilobytes per page — because it stores characters and font references. A PDF made from photographs of paper stores a full image per page, which is typically 200 KB to 2 MB each. Merging ten scanned pages therefore produces a file ten times larger than merging ten text pages, and nothing has gone wrong.

Three ways to bring it down, in order of how much they cost you:

1. Scan with a document scanner, not the camera. The scanner mode in the Notes app detects edges, flattens perspective and compresses for text. The difference against a photograph of the same page is usually several times the size.
2. Reduce the export quality once, at the end. Preview's Quartz filter and most phone apps offer a smaller-file export. Do it on the merged document rather than each part.
3. Convert scans to text where you can. If the content is text, OCR turns images into characters and the file shrinks dramatically — with the side effect that the document becomes searchable.

The third option is the one worth reaching for when the document has a future. A scanned page you cannot search is a picture of information; the same page as text is information.

Where does the page range go wrong?

Page ranges are the one part of a split PDF operation that produces a confidently wrong result rather than an obvious failure, and three mismatches account for most of it.

The printed page number is not the file page number. A report whose body starts at "page 1" after a cover and a contents page is offset by two, so asking for pages 12–18 gives you what the document calls 10–16. Always count from the thumbnail view, which numbers the file rather than the layout.

Double-sided scans include the blank backs. A twenty-sheet document scanned duplex is a forty-page file, half of it empty. Splitting by an expected count rather than by looking produces ranges that drift further wrong the deeper into the file you go.

Inclusive ends. Almost every tool treats a range as inclusive of both ends, so 12–18 is seven pages, not six. Command-line tools follow the same convention, but scripts written around them frequently do not.

There is also a quieter case worth knowing: some documents carry a page-label scheme, where the front matter is numbered in roman numerals and the body restarts at 1. A viewer showing "iv" and a tool asking for page 4 are not talking about the same thing, and the only reliable reconciliation is the thumbnail index.

The habit that avoids all four is the same: select the pages visually and extract the selection, rather than typing numbers you inferred. Where you must type numbers, open the result and check its first and last page before doing anything else with it.

When a phone is the wrong tool

Three situations where the built-in path stops being enough.

Many files at once. Merging forty documents by hand is a mistake waiting to happen, and so is a repeated split PDF job across a folder. This is a desktop scripting job, and pdfunite or qpdf do it in one line.

Password-protected files. Most built-in tools refuse to split PDF content that is encrypted until it is unlocked, and unlocking requires the password — which is the point of it.

Forms and signatures. Splitting a signed PDF invalidates the signature, because the signature covers the whole document as it was. Merging a fillable form usually flattens the fields, which discards entered data. If the file has either, work with the original and be careful.

The signature case surprises people who assume that extracting a page preserves everything on it. Visually it does. Cryptographically it does not, and a recipient checking the signature will see it as broken.

Reading and checking the result

Whatever produced the file, open it once before sending. Two specific checks catch nearly every embarrassing outcome: page count against what you expected, and the first and last page against what you meant to include.

For documents that are text rather than scans, a plain reader such as Mdora is a fast way to confirm the content came through as text and not as an image of text — if the words are selectable, they are text. It is a five-second check that decides whether the file is searchable for whoever receives it.

More on the surrounding tasks in file tools, text extraction in text tools, and the general principle of preferring on-device tools in online tools. If you do need the command line, the qpdf manual documents the split and merge syntax.

The short version

To split a PDF on a phone, use the print dialogue with a page range and save the preview back out. To merge, select the files in the order you want and create a PDF from the share sheet. Neither re-encodes the pages.

Check the order after merging, remember that a split file keeps the original's metadata and annotations, and be wary of signed or fillable documents — those are the cases where splitting quietly destroys something you cannot see.