A PDF that fails to open is a good outcome. You find out immediately and you still have the original.
The outcome worth worrying about is the file that opens, renders, prints, and is missing a form field, a font, an accessibility layer or a signature. Most PDF operations can produce that file, and almost none of them warn you. So the useful way to rank these operations is not by which tool is best at each, but by how quietly each one can hand you a plausible wrong answer.
Compression is two unrelated operations wearing one name
“Compress this PDF” means one of two things, and conflating them is where the damage starts.
Lossless structural rewriting deduplicates repeated resources, drops orphaned objects, recompresses streams and linearises the file. qpdf does this. Your text stays byte-for-byte the same glyphs; you typically recover a modest amount from a bloated export. No quality cost, and nothing to check afterwards beyond the file opening.
Lossy image resampling downsamples the embedded raster images and re-encodes them. This is where the dramatic reductions come from, and it is destructive. Ghostscript’s -dPDFSETTINGS presets are exactly this knob: /screen targets the lowest image resolution and /ebook a higher one, among others.
The trap is that Ghostscript’s pdfwrite device does not edit your file. It interprets it and writes a new one. That is a full round-trip through an interpreter, and things that were in the input and are not in Ghostscript’s output model do not survive: form fields, annotations, embedded attachments, digital signatures, tagged-PDF accessibility structure, and layer (OCG) organisation are all at risk depending on version and options. The output opens perfectly. It just is not the same document.
So: if the file is a scan and you want it smaller, resampling is the right tool. If the file is a form, a contract, a signed document, or anything with accessibility tagging, reach for the lossless path and accept the smaller win.
Merge and split break things outside the page
Concatenating page trees is easy. What breaks lives outside the page content:
- Bookmarks and outlines frequently vanish or flatten, because the outline tree references pages that just got renumbered.
- Internal links become dangling for the same reason. A table of contents that scrolls to the wrong page is a merge artefact.
- Form field names collide. Merge two copies of the same form and you now have two fields with identical names. Depending on the viewer, filling one fills both.
- Duplicate resources balloon the file when the merger does not deduplicate shared fonts and images.
None of these produce an error. The reliable check is to reopen the merged file and exercise the navigation, not just look at page one. qpdf --check will tell you whether the structure is sound, which is necessary but not sufficient: a structurally valid PDF can still have an outline pointing at the wrong pages.
Conversion: fidelity claims are mostly marketing
Office-to-PDF is largely a font problem. If the converter does not have the font, it substitutes, and substitution changes metrics, which reflows lines, which moves page breaks. The document is now a different length. Nothing warns you.
PDF-to-Office is worse in a different way: it is a reconstruction, not a conversion. There is no paragraph structure in a PDF to recover, only positioned text runs, so the converter infers it. The output is a plausible guess that a human has to check line by line. Treat it as a starting point, never as a result.
The practical rule for both: embed fonts on the way in, and never treat a round trip as lossless.
OCR is the safe one, and the most misapplied
OCR does not modify your page; it adds an invisible text layer behind the image. That makes it the safest operation on this list, and it is also the one people apply to the wrong files.
The misuse is running OCR on a PDF that already has real text. A digitally generated PDF has selectable text with exact glyph positions. Rasterising it and OCRing the raster replaces perfect text with a statistical guess. Check for an existing text layer first; if you can select text in a viewer, you do not need OCR.
Where OCR does matter, the quality of the input dominates everything. A 150 DPI scan of a fax will not be rescued by a better engine. Rescanning at 300 DPI will.
Signing is supposed to be fragile
A digital signature covers a byte range of the file. Any operation that rewrites the file invalidates it. That is not a bug; it is the entire purpose. If you can compress, merge or optimise a signed PDF and the signature still validates, something is wrong with your validator.
The consequence for a pipeline is simply ordering: sign last. Every optimisation, every merge, every metadata edit happens before the signature, never after. I have watched a “helpful” compression step at the end of a workflow silently void every document it touched.
Who sees the bytes
Worth naming separately, because it is a decision people make by accident. A browser-based tool that does the work client-side never transmits the file. A server-side tool uploads it. For an invoice that is irrelevant; for anything under NDA, a contract, medical or identity documents, it is the only question that matters.
The way to tell is not the marketing copy on the page. Open the network panel, run the operation, and see whether a request carries your file. If it does, the answer is server-side regardless of what the page says.
The short version
Lossless before lossy. Check navigation after a merge, not just page one. Embed fonts before converting, and never round-trip. Look for a text layer before OCRing. Sign last. And if the document is confidential, verify in the network panel rather than trusting a claim.