Working With PDFs

A PDF page is a self-contained thing

The reason merging and splitting are lossless is structural. A PDF is not a stream of content the way a Word file is; it is a collection of objects — fonts, images, colour spaces, and content streams of drawing instructions — plus a page tree saying which objects make up each page and in what order they appear.

Because a page references everything it needs, it can be lifted out and dropped into another document intact. A good merge tool copies the page object along with the resources it points at, and the result renders identically to the original. Nothing is re-rendered, re-compressed or flattened, which is why text stays selectable and images keep their exact resolution.

This is worth knowing because it tells you when to be suspicious. If a tool produces a merged file where the text has become unselectable or noticeably blurry, it has rasterised your pages — converted them to images — rather than copying them. That is a real quality loss and an unnecessary one.

The merge and split tool copies pages rather than re-rendering them, and does it in your browser so the documents never leave your device.

Page ranges: the syntax worth learning

Page-range notation is near-universal across PDF software, print dialogs and command-line tools, and knowing it properly saves a lot of clicking.

Two details cause most of the confusion. Ranges are inclusive at both ends — 2-6 gives you five pages, not four. And page numbers here are positions in the file, not whatever is printed on the page. A document with roman-numbered front matter will have its "page 1" several sheets in, and the tool counts from the physical first page regardless.

The reversing behaviour of a descending range is not universal, but it is genuinely useful — most often for fixing a batch of pages scanned in the wrong order.

Why merged files can balloon

A common surprise is a merged PDF noticeably larger than the sum of its parts. The usual culprit is fonts. Each source document embeds subsets of the fonts it uses, and a straightforward merge carries all of them across. Ten documents that each embedded the same typeface produce one file with ten near-identical font subsets in it.

The same applies to any repeated image — a letterhead or logo appearing in every source arrives ten times over. Deduplicating these requires comparing object contents across documents, which is a considerably harder operation than copying pages, and most merge tools quite reasonably do not attempt it.

If size matters, the fix is a separate compression pass afterward rather than a cleverer merge. Tools that "optimise" a PDF are typically doing exactly this: subsetting fonts down to the glyphs actually used, deduplicating identical objects, and recompressing images. Do it after merging, not before, or you will just do it several times over.

Splitting, and choosing where

Splitting comes in two shapes and it is worth being deliberate about which you want.

Fixed-size splitting divides a document mechanically — one file per page, or one per five pages. This is right when the structure is regular: a batch of scanned invoices at one page each, or a bundle of two-page forms.

Range extraction takes exactly the pages you name and is right when the structure is not regular. Pulling chapter three out of a report, or the two pages of an eighty-page contract that actually need signing, is an extraction rather than a split.

There is a practical reason to prefer extraction when sending documents on. A bank statement or medical record often contains far more than the recipient needs, and sending the whole file because it was easier is one of the most common accidental disclosures there is. Extracting the relevant pages takes seconds and is the difference between sharing one transaction and sharing a year of them.

What splitting does not remove

A crucial caveat: taking pages out of a PDF removes the pages, but a PDF carries information that is not attached to any page, and some of it survives.

Document metadata — author, title, producing software, creation and modification dates — belongs to the document, and tools generally start a fresh document when extracting, which drops it. That is usually desirable, though it means a carefully set title disappears too.

Bookmarks and links that pointed to pages you did not keep necessarily break. Well-behaved tools drop the dangling ones; less careful ones leave links that go nowhere.

The one that genuinely catches people out is redaction. Drawing a black rectangle over text in a PDF editor covers it visually while leaving the text underneath perfectly intact and selectable. Splitting the page out carries the hidden text with it. Real redaction removes the underlying content, and this distinction has produced a long series of embarrassing disclosures from organisations that assumed a black box was enough.

Getting the order right when merging

Merge order is the source of more wasted effort than any other part of this job, and almost all of it traces back to one thing: file managers sort names as text, not as numbers. Select twelve files called scan-1.pdf through scan-12.pdf and they arrive in the order 1, 10, 11, 12, 2, 3 — because "10" sorts before "2" alphabetically. The merged document looks plausible at a glance and is thoroughly out of order.

The fix is zero-padding: name files scan-01.pdf to scan-12.pdf and text sorting and numeric sorting agree. It is worth doing at the point of scanning rather than afterwards, and it pays off every time those files are touched again.

The second common ordering problem is double-sided scanning on a single-sided feeder. Scanning all the fronts and then all the backs gives you one file of odd pages and one of evens, and merging them end to end produces a document with every page in the wrong place. What you need there is an interleave rather than a concatenation — and if the backs were fed in reverse, the second stack also needs reversing first, which is precisely what a descending page range is for.

Whatever the source, check the joins. Look at the last page of each section and the first page of the next: mistakes almost always show up at a boundary, and scanning four or five transitions takes seconds compared with reading the whole document.

Passwords and permissions

PDF has two different kinds of password and they behave completely differently.

A user password is required to open the document at all. The content is genuinely encrypted, and without the password there is nothing any tool can do.

An owner password sets permissions — no printing, no copying, no editing — while leaving the document openable by anyone. These restrictions are advisory: the content is not protected, and compliance depends entirely on the viewer choosing to honour the flags. Most libraries can read straight through an owner password, which is why "printing restricted" documents can usually still be merged and split.

It is worth being clear-eyed about that rather than treating it as a loophole. Owner-password restrictions were never a security mechanism, and if a document genuinely must not be redistributed, permissions flags are not the tool for the job.

Why browser-based matters here

PDF tools are a category where where the processing happens is not a technicality. Think about what people actually merge and split: contracts, payslips, bank statements, medical letters, tax returns, scans of passports and driving licences. That is close to a complete list of the documents you would least like to upload to an unknown server.

A browser-based tool reads the file into memory locally and rebuilds it there. Nothing is transmitted, which removes the question of retention policies entirely — there is no copy on anyone's disk to retain. It also removes the practical annoyances that come with server processing: no file-size cap chosen to control someone's bandwidth bill, no queue at busy times, no watermark on the free tier, and it keeps working offline once the page has loaded.

The trade-off is your device's memory. A five-hundred-page scanned document held in memory while a second copy is built can be genuinely demanding on an older phone. For everyday documents this never comes up, and it is a fair price for not uploading your tax return.

There is a simple way to tell which kind of tool you are using, incidentally: watch what happens when you drop a file in. If there is a progress bar and a wait proportional to your connection speed rather than your file size, it is uploading. If a large document is ready almost instantly on a fast machine and slowly on an old one, the work is happening locally. It is worth checking before feeding anything sensitive to a site you have not used before.

A short history of why PDFs are like this

Some of the format's quirks make more sense with a little context. PDF was created at Adobe around 1993, growing out of a project to make documents that would look identical on any machine and any printer — a genuinely hard problem at a time when a file could render completely differently depending on which fonts a computer happened to have installed.

The solution was to make a PDF a description of marks on a page rather than of content with meaning: place this glyph at this coordinate, in this font which is embedded right here. That is why PDFs reproduce so faithfully and why they are so awkward to edit. There is no paragraph in a PDF, only a series of positioned glyphs that happen to look like one, which is why "editing" a PDF is more like retouching a photograph of a document than like using a word processor.

It also explains why extracting text from a PDF is unreliable in a way that surprises people. The glyphs are positioned individually, and reconstructing reading order, word boundaries and columns from coordinates is guesswork. It usually works and sometimes produces nonsense, particularly with multi-column layouts and tables.

The format became an open ISO standard in 2008, which is why so many independent tools can read and write it. That openness is the reason a PDF library can run in a browser at all — and therefore why the documents you merge here never need to be uploaded anywhere.

Practical habits

Check the page count before and after. The single most common merge error is a document added twice or omitted, and comparing totals catches it instantly.

Name files so they sort correctly. If you are merging scans, part-01 through part-12 sorts properly where part-1 to part-12 does not — 10 comes before 2 alphabetically, and that is how a great many out-of-order merges happen.

Extract before sending, not after. Once a full document has gone, trimming your local copy achieves nothing.

Keep the original. Merging and splitting are lossless but not reversible — you cannot recover the original boundaries from a merged file, so keep the sources until you are certain.

Open the result before you send it. It takes ten seconds and catches the errors that matter: a page upside down, a section duplicated, a scan that came through blank. Nobody has ever regretted the ten seconds.

Try it in the merge and split tool. If you need to edit content rather than rearrange pages the PDF editor handles that, PDF Studio covers conversion, and PDF to JPG is there when you need pages as images.