Most people pick a compression tool based on a handful of sayings that sound right but fall apart on real documents. Let them sit here, then we take each one apart, then we look at what an engineering-grade pipeline actually looks like.
The "common sense" most people carry
First, the higher the advertised compression ratio, the better the tool — whoever dares claim 90% must be the strongest.
Second, every file should shrink dramatically; if it won't, the tool is weak.
Third, online compression sites and local tools do the same job — both just compress.
Fourth, compression damages files; compress a signed contract and the seal goes blurry.
Fifth, compression is a one-step job; a single slider handles every format.
None of these five holds up.
Myth 1: A higher ratio is always better — the mistake of using an absolute number as the yardstick
A compression ratio is not an absolute figure; it is a proportion of "redundancy." Shannon's information theory gives the conclusion: any part of a dataset predictable from its context is redundancy, and compression simply re-encodes that redundancy with shorter codes, approaching the data's "entropy" floor.
A plain example. In a Chinese passage the character "de" appears extremely often, while a rare character shows up seldom. Assign shorter bit-sequences to common characters and longer ones to rare characters, and the whole text comes out far shorter than if every character got equal length. Compression does not destroy information; it stops over-paying bits for the predictable parts.
The catch: formats already near the entropy floor — JPEG, MP4, ZIP, and PDFs whose images are already optimized — have almost no room left. That is not a weak tool; the substrate has hit its ceiling. The right question is "for your kind of file, how much redundancy is actually there," not "why isn't someone's advertised 90% showing up on my file." Tools that lead with a big number usually only hit it on a specific sample.
Myth 2: A stubborn file means a weak tool — ignoring the file's own substrate
Documents differ far more than most people assume. An unoptimized PDF, Office file, or scan hides large redundancy inside its size: the same company logo or font embedded dozens of times instead of referenced once; screenshots and scans stored at resolutions well beyond what display needs; edit history, redundant structure trees, and hidden thumbnails quietly taking space.
Strip that redundancy and you often remove 60 to 80 percent. Reverse it: an image already compressed, a container already packaged, simply has little redundancy left, so refusing to shrink is the norm. "Won't compress" usually means a thin substrate, not a poor engine. To read compression results, first see how much squeezable water the file actually holds.
Myth 3: Online and local are the same — treating "data leaving your perimeter" as a minor detail
Compression is compute-intensive yet highly sensitive. Drag an unsigned contract or a report with customer data into an online compression site, and the file has, in that instant, left your device and entered a third-party server. IBM's 2025 data-breach report carries a figure easy to miss: 26 percent of breach causes were human error — more mundane, and more common, than external attack. Handing sensitive files to an unknown online tool is exactly the avoidable, human-caused exposure class.
Finishing the job locally is the steadier pattern: data never leaves the device, so the privacy ledger settles itself; local batch processing is also free of network bandwidth and concurrency limits. For teams under compliance pressure, making "processing data stays inside the internal network" a hard requirement tends to beat auditing after the fact.
Myth 4: Compression blurs seals — failing to separate lossless from lossy
Engineering splits compression into two classes. Lossless guarantees the decompressed file is byte-for-byte identical to the original; documents, code, and data — content where a single wrong byte breaks things — must go lossless. Lossy actively discards details the human eye or ear will not notice, in exchange for size; images, video, and audio rely on perceptual coding, exploiting the fact that human vision is insensitive to high-frequency detail and chroma, dropping the imperceptible first.
The hard part: a PDF or Office document is fundamentally a "hybrid." It carries text structure and vector graphics that must stay lossless, while embedding large bitmaps, screenshots, and scan pages that could have been perceptually re-encoded. Driving one parameter set through everything is exactly what corrupts the text structure that should be preserved, or wastes effort on images already optimized. The correct move is divide-and-conquer: text and structure take the lossless path, embedded images get perceptually re-encoded on their own, duplicate objects get deduplicated — each to its own optimum.
This also explains why long-term archival cares about layout fidelity. Archival standards for electronic records emphasize that compression may only touch redundancy, never layout or verifiability — which is not in conflict with the requirement itself.
Myth 5: One slider fits all — underestimating scenario trade-offs
Compression was never "the smaller the better"; it is "small enough, under your constraints." Three typical scenarios trade off completely differently: in archival, time is not the bottleneck, so you can compress harder and chase the lowest long-term storage and transfer cost; in email attachments, the goal is "small enough to send" while seals, signatures, and tables stay clearly readable, so quality leads; in web and mobile, lightness leads, balancing open speed.
A further engineering value is "consistent cross-format sizing": the same batch, whether PDF, image, or Office, lands in a consistent size range after compression, so you stop guessing "will this come out too small or too big" for every file.
How we turn these insights into engineering
To make the five points concrete, an engineering-grade compression pipeline needs at least four things.
First, a divide-and-conquer pipeline. Text structure lossless, embedded images perceptually re-encoded, duplicate objects deduplicated — each to its own optimum. Only when the embedded images and objects inside a document are also pulled into the unified pipeline (not just the outer container) does the overall gain actually materialize.
Second, scenario-based tiers. Archival, email, and web each get their own sizing; cross-format results stay consistent, so users stop guessing per file.
Third, local-first. Files always stay on your own device; batch processing is also free of network and concurrency limits. For teams guarding a compliance baseline, making "files stay inside the internal network" a hard constraint of the process is steadier than auditing after something goes wrong. This also explains why a pipeline built natively for the hardware — one less translation layer — wins enterprise favor: lighter to deploy, more controllable in behavior, more reproducible in output, and smoother for private deployment.
Fourth, leverage awareness for scaled cold data. Komprise's customer research shows 60 to 70 percent of enterprise NAS data has not been touched in over 90 days, yet still occupies the most expensive primary storage. Squeeze that redundancy and the savings are real storage bills.
What dimensions to weigh when choosing
Put the three common approaches side by side; the differences are mainly in data destination, format coverage, batch and tiering ability, and compliance control:
| Dimension | Local compression tool | Online compression site | Manual ZIP / DIY |
|---|---|---|---|
| Data destination | Entirely on-device, never leaves | File uploaded to third-party server | On-device, but limited ratio |
| Format coverage | Common and professional formats handled uniformly | Common formats; complex ones often unsupported | Depends on personal skill |
| Batch & tiering | Tiered by use; consistent cross-format sizing | Mostly one file at a time | Almost no tiering concept |
| Compliance control | Stays inside network, fits enterprise policy | Hard to meet enterprise compliance | Controllable but inefficient |
If your files are mainly office documents, scans, and common images, a local compression tool is the best value. When the volume grows large enough to need automated archival, or you want to tie compression into file retrieval and organization, you can design "compression" and "file organization" as one workflow — for example, use MagiFiler to tidy the material first, then slim it uniformly with SmartSlim; the two together beat handling them separately.
FAQ
Q: Why won't some PDFs compress much?
A: Likely its embedded images are already optimized and near the entropy floor, or its size is mostly lossless text structure. That's not tool failure; the redundancy was simply small to begin with.
Q: Will compression blur the seals or signatures on a contract?
A: A light re-encoding path that preserves detail targets redundant volume, not clarity. For scans and seal-bearing documents, open and verify the key spots after compressing before archiving.
Q: Big volume difference between local and online compression?
A: On real documents, both often remove a substantial portion; the difference is less "how much" and more "whether the file visited a third party." Public material via online tools is fine; files with sensitive information are better handled locally.
Q: Can every format be compressed?
A: Common office and image formats, and scans, usually have room; already heavily optimized formats gain little. Specialized long-tail formats — medical imaging, geospatial, LiDAR — often need targeted strategies, not generic parameters.
String the points together and the truth about document compression is plain: first see where the redundancy is, handle it by type, and balance under your scenario constraints. A tool that does "divide-and-conquer, finish locally, stay consistent across formats" is the most painless day to day.
If this need lands in your workflow, evaluate tools by this reasoning rather than a single compression-ratio number. For more engineering notes on file handling and local-first thinking, see https://www.uglypear.com/blog/ .