Why merging is nearly free, compressing is not, and some PDFs refuse to be searched.
A PDF behaves like a stack of paper, which is exactly what its designers intended and exactly what makes its actual behaviour surprising. Files balloon for no obvious reason. Some are searchable and some are not. Merging two documents takes an instant while shrinking one takes ages and degrades it. All of that follows from what a PDF really is underneath.
The most useful correction: a PDF page is not an image. It is a program — a sequence of drawing instructions saying "set this font at this size, move to these coordinates, draw this text, stroke a line from here to here, paint this image into this rectangle". A PDF viewer is an interpreter that executes those instructions.
This is why you can select text in a PDF, why a page stays crisp at 800% zoom, and why the same file prints identically on different machines. It is also why a PDF made by scanning paper behaves so differently: there the instruction list says only "paint this photograph across the whole page", and there is no text anywhere in the file.
A PDF file is a collection of numbered objects. An object can be a number, a string, a name, an array, a dictionary of key-value pairs, or a stream — a dictionary followed by a block of raw bytes, usually compressed. Streams hold the bulky things: page content, embedded fonts, images.
Objects reference each other by number. A page object points to its content stream and to a resources dictionary; that dictionary points at the font and image objects the page uses. The whole document is a graph of these references, rooted at a catalog object.
At the very end of the file sits the cross-reference table, or xref: a directory listing the byte offset of every object. After it comes a trailer naming the root object. A viewer opens a PDF by seeking to the end first, reading the xref, and then jumping straight to whichever objects it needs.
That design has a real consequence: a viewer can render page 400 of a 500-page document without parsing the first 399. It also means the byte offsets in the xref must be correct. Edit a PDF with a text editor, change the length of anything, and every subsequent offset is wrong — which is why a file that looks fine in a text editor can be rejected as corrupt.
PDF supports appending changes rather than rewriting. Add an annotation and a well-behaved editor writes the new objects at the end, followed by a fresh xref that overrides only the entries that changed, chained to the old one.
This makes saves fast and preserves the exact bytes of what was signed, which is how digital signatures survive later annotation. It also means a PDF can still contain earlier versions of its own content. Text that was covered with a black rectangle is a particular trap: the rectangle is a new drawing instruction painted on top, and the original text object is very often still sitting in the file, fully extractable. Genuine redaction has to remove the underlying objects and rewrite the file, not draw over them.
Merging sounds like it should be expensive and is not. To combine two PDFs:
No page is re-rendered. No image is re-encoded. No text is re-laid-out. The content streams are copied through byte for byte, so merging is lossless — page 3 of the merged file is bit-identical in its drawing instructions to page 3 of the original. It is essentially a bookkeeping exercise, which is why it completes almost instantly even on large documents.
Splitting is the same operation in reverse: keep the pages you want, walk the reference graph to find the objects they depend on, discard everything unreachable, write a new xref.
If both documents embed the same font, the merged file usually contains it twice. The two font objects are separate objects from separate files, and a merger cannot safely assume that two fonts with the same name are byte-identical — they are frequently different subsets.
Which brings us to subsetting. Embedding a full font can cost hundreds of kilobytes, so producers usually embed only the glyphs actually used. Two subsets of the same typeface can contain quite different glyph sets, so merging them naively means carrying both.
Compressing a PDF is a completely different operation, and unlike merging it is usually lossy. The tools available:
Note that only the last three are lossless. When a compressor reports a dramatic saving on a scanned document, it has re-encoded the scans, and the quality cost is real even if it is invisible at normal zoom.
A text-only PDF that is already well produced may barely shrink at all. There is nothing left to remove: the text is a few kilobytes of instructions, the fonts are already subset, the streams already compressed. If a "compressed" version of such a file comes back the same size, the tool is working correctly.
There are two kinds of PDF that look identical on screen.
A digital PDF was generated from a document — exported from a word processor, printed to PDF from a browser. Its pages contain text-drawing instructions with real character codes, so text can be selected, searched, copied and extracted exactly.
A scanned PDF came from a camera or scanner. Each page holds a single image and nothing else. There is no text in the file, so searching finds nothing, selecting selects nothing, and copying copies nothing. The words are visible only in the sense that they are patterns of dark pixels.
Optical character recognition bridges the gap by analysing the image, recognising glyph shapes and adding an invisible text layer positioned over the picture. The image still renders; the hidden text makes it searchable. This is why OCR'd documents sometimes let you select text that does not quite match what you see — you are selecting the recognition result, complete with any mistakes it made.
Even genuine digital PDFs can extract badly. The content stream stores glyph codes and positions, not words: there is no explicit space character in many PDFs, only a horizontal move between glyphs. Extractors infer word boundaries from gap sizes, which is why extracted text sometimes runs words together or splits them apart.
Worse, a font can use a custom encoding where glyph code 1 means "A". Without a correct ToUnicode mapping in the font object, extraction produces confident gibberish. The page renders perfectly, because rendering only needs "draw glyph 1", while extraction needs to know what glyph 1 means.
Multi-column layouts add their own problem: the drawing order reflects how the producer emitted the page, not how a human reads it, so naive extraction can interleave columns.
PDF has two separate mechanisms, often confused.
A user password genuinely encrypts the content. Without it the objects cannot be decoded. Modern PDFs use AES, and this is real protection.
An owner password with permission flags — "printing not allowed", "copying not allowed" — is advisory. The file is readable; it merely carries flags asking viewers to restrict certain actions. Compliant software honours them; nothing enforces them. Treat permission flags as a politeness convention, never as security.