A 20-page report with embedded images can easily hit 50MB. That's too big for most email attachments, too slow to share, and a waste of storage space. So you need to compress it.
Most people assume that means trading quality for size — blurrier photos, fuzzier text, a document that looks worse just because it's smaller. It doesn't have to. Once you know what's actually eating the space inside a PDF, you can shrink it hard without losing quality anywhere a reader would notice.
Short answer: Compressing a PDF without losing quality means fixing what's actually bloating the file — oversized images and unused font data — instead of degrading everything evenly: resample images to their real display resolution, drop unused glyphs and metadata, and treat quality reduction as a last resort.
Why PDFs Get So Large
Images
This is almost always the answer. A single high-resolution photo can easily run 5-10MB uncompressed. Scanned PDFs are the worst offenders — each page is stored as one full-page photograph, so a 20-page scan is really 20 separate images glued together.
If your PDF started life as a scan, compression can shrink it a long way, but it won't make the text searchable — the page is still a picture of text, just a smaller one. Getting the words themselves back out needs OCR, a separate step that extracts them as copyable, searchable text rather than adding a hidden layer to the PDF.
Fonts
PDFs can embed entire font files so the document looks identical on any machine, in any viewer, without depending on fonts the reader happens to have installed. A single font family with all its weights and styles can add several hundred kilobytes, and documents routinely embed three or four families between body text, headings, and code blocks.
Metadata and Cruft
Layers, form fields, bookmarks, revision history, embedded thumbnails, scanner metadata — none of it is visible on the page, and all of it takes up bytes. Scanned documents in particular tend to carry metadata nobody will ever read: the make and model of the scanner, a timestamp, sometimes a color profile repeated on every page.
If metadata removal is the actual goal — a document with no images to shrink, just years of edit history and hidden fields to clear out — Sanitize PDF does exactly that, without touching page content at all.
Duplicate Resources
Some PDF generators are lazy about deduplication. They'll embed the same logo, background image, or font file once per page instead of storing it once and referencing it everywhere it's used.
This shows up constantly in merged documents, too — five files that each embed a company letterhead become one file with five copies of the same letterhead, because merging PDFs concatenates resources rather than deduplicating them. If you just merged a batch of files and the result is unexpectedly heavy, that's often exactly why, and compression is what cleans it up afterward.
Strategies That Actually Work
These are the levers most PDF compressors — desktop or browser-based — combine to shrink a file without visibly touching quality. Which ones a given tool actually runs varies; OxygenPDF's own approach is covered in detail further down.
Image Resampling
Resolution matters more than compression level. A photo scanned or embedded at 300 DPI but displayed on a screen at 72-150 DPI is carrying four to sixteen times more pixel data than anyone will ever see rendered. Reducing the DPI to match how the image is actually displayed removes information that was already invisible — not information anyone would notice losing.
Rough guidelines: 150 DPI is plenty for on-screen reading. 200-300 DPI holds up for most printing. Higher than that is really an archival decision, not a viewing one — the Library of Congress's own preservation digitization guidelines put text and manuscript scanning at 300-400 ppi, reserving 400-600 ppi for rare or fragile originals, rather than the "as high as possible" instinct people sometimes apply to archival work.
This is the lever OxygenPDF's compressor pulls directly — its DPI setting is exactly this resampling step, applied to every page.
Font Subsetting
If a document only uses 60 distinct characters from a font — the alphabet, numerals, basic punctuation — there's no reason to embed the font's entire character set. Subsetting keeps only the glyphs actually used and discards the rest.
A font file can technically hold up to 65,535 glyphs, because the format stores each glyph's ID in a 16-bit field, per the OpenType specification's maxp table — but that's a ceiling built into the file format, not a typical embedded count. Most fonts most documents actually use hold a few hundred to a couple of thousand glyphs in total, and a subsetted font for a single-language document can drop to well under 100.
OxygenPDF's compressor doesn't subset fonts, because it doesn't keep fonts at all after compression — see "What Compression Actually Changes" below for what happens instead.
Metadata Stripping
Remove creation-software tags, edit history, embedded thumbnails, and redundant internal structure, and you typically save a few hundred kilobytes with zero visual impact, since none of it was ever rendered on the page.
Building a document from scratch, rather than editing the existing one in place, strips all of this automatically as a side effect — there's nothing left to carry over. That's true of OxygenPDF's compressor too, and it's one reason its output carries none of the original file's bookmarks, form fields, or embedded metadata. More on that trade-off below.
Object Stream Optimization
A PDF's internal structure — how objects are indexed, cross-referenced, and stored — can be reorganized to group related objects together and encode the cross-reference table more compactly. PDF 1.5, released in 2003, added support for exactly this: compressed object streams and cross-reference streams (per the format's version history). It's the kind of saving you never see happen, but it adds up across a document with a lot of small objects — form fields, annotations, deeply nested bookmarks.
This matters most for structurally complex, image-light PDFs. If a file is mostly vector text and already fairly lean, this — not image resampling — is usually where the remaining size is hiding, and it's a different problem than what a DPI or quality slider solves.
Compressing with OxygenPDF
- Open the Compress PDF tool
- Drop your file in — a password-protected PDF works too; enter the password when prompted and compression runs normally from there
- Pick a preset, or switch to Target Size mode if you need to hit a specific file size
- Download the result
Everything runs locally in your browser. The file is never uploaded anywhere.
The Four Presets
| Preset | Image DPI | JPEG quality | Typical reduction | Best for |
|---|---|---|---|---|
| Light | 200 | 85% | 30-40% | Documents you'll print |
| Balanced | 150 | 75% | 50-60% | General sharing, email |
| Maximum | 100 | 60% | 70-80% | Screen-only viewing |
| Extreme | 72 | 35% | 85-95% | Smallest possible file |
These are the tool's own settings and its own stated expectations, not universal numbers — how close your file lands to them depends on how much of it is images versus text to begin with. A "Fine-tune" panel under each preset lets you move the DPI (50-300) and JPEG quality (10-100%) sliders independently if none of the four presets land where you want.
Target Size Mode
If you need the output under a specific size — a portal with a 5MB upload cap, an email provider that caps attachments at 25MB — Target Size mode takes a number in megabytes and works backward from it. It samples a handful of representative pages (the first, the last, the middle, and a few spread through the rest of the document) at several DPI and quality combinations, estimates the output size from those samples, and picks the highest-quality setting that should land under your target. If even the most aggressive setting can't get there, it says so rather than pretending.
What Compression Actually Changes
Here's the part most compression guides skip: what actually happens to the file. OxygenPDF's compressor renders each page as an image at your chosen DPI and JPEG quality, then rebuilds a new PDF from those images — rather than recompressing embedded photos in place while leaving vector text and line art untouched, the way some desktop PDF editors do. That's a deliberate trade for consistency: it treats a scanned page and a text-native page the same way, which is also why the DPI setting matters even on a page that has no photos on it at all.
The trade-off is that text stops being text. Even at the Light preset, the words on a compressed page are pixels, not characters — you can't select them, search them, or copy them, and a screen reader can't read them either. At 200-300 DPI they still look sharp on screen and in print; at 72 DPI they'll visibly soften. If you need the text to stay selectable and searchable after compressing, this approach isn't the right one for that file — skip compression for it, or compress a duplicate and keep the searchable original.
The same rebuild-from-scratch process is also why bookmarks, hyperlinks, fillable form fields, comments, and embedded metadata don't survive compression — there's nothing in the output to carry them, since the whole document is new. Flatten PDF does something narrower on purpose: it merges fillable form fields into static page content and leaves everything else — hyperlinks, bookmarks, the underlying vector content — untouched. Compression's version is broader and incidental: because the whole page becomes a picture, form fields, links, bookmarks, and annotations all disappear together, not just the fields. If a file still needs working form fields or an intact table of contents afterward, compress a copy rather than your only version.
One more consequence worth knowing: a lean, mostly-text PDF that's already small can come out the same size, or even larger, after compression, because a rasterized page of plain text at a reasonable DPI often takes more bytes than the vector text it replaced. OxygenPDF's tool detects this and says so directly — "already optimized, similar size" — rather than handing back a bigger file with no explanation. If you see that message, the file genuinely wasn't worth compressing.
Grayscale and Batches
A grayscale toggle, available in both the preset and Target Size views, drops color data from every page — useful for scanned line drawings, forms, and black-and-white originals that got scanned in color by default. It meaningfully shrinks output built from photos or color scans; how much depends on how colorful the original pages actually are.
Multiple files can be queued and compressed with the same settings in one pass, which is the practical option for a folder of scanned receipts or a batch of reports that all need the same treatment before archiving or emailing.
What to Expect
The chart above illustrates typical outcomes, not a benchmark run against a fixed test set — your results depend on the actual mix of images, fonts, and page count in your file, not the document type alone. For a number you can hold the tool to, use the preset table earlier in this article: 30-40% for Light through 85-95% for Extreme, drawn directly from the compressor's own settings.
Image-heavy scans compress dramatically, because most of their size was resolution nobody needed. Text-only PDFs that are already lean, as covered above, may barely shrink, or may not shrink at all — and that's expected behavior, not a malfunction.
When to Skip Compression
Don't compress legal documents where any modification could affect their validity or admissibility. Courts and counterparties sometimes care about exact provenance, and rebuilding a file from rasterized pages changes it at a level deeper than what's visible on screen.
Skip it for print-ready files where exact DPI needs to be preserved. A print production workflow with bleed and registration marks depends on precise page geometry, and while compression doesn't change page dimensions, it does resample everything on the page to a single DPI you chose — not the same thing a print shop's RIP expects from embedded high-resolution source images.
Skip it, too, for anything that still needs to function as a form, needs its hyperlinks or table of contents to work, or needs its text to stay selectable and searchable. As covered above, none of that survives OxygenPDF's compression step, because the page becomes an image.
For archival copies, decide first whether long-term fidelity matters more than disk space. If it does, keep the original and compress a duplicate for everyday use. Storage is cheap, and a compressed copy that turns out to have thrown away something you needed is not something you get back.
If a file arrived with a password, compression handles that directly — enter the password when the tool asks for it, and it decrypts and recompresses in one step. If you want the password gone permanently rather than just handled during compression, removing it first is the separate job for that.
FAQ
Does compressing a PDF always reduce quality?
Visually, not necessarily. The Light preset (200 DPI, 85% JPEG quality) is close to indistinguishable from the original on screen and in most printing for typical content. What does always change, at any preset, is whether the text stays selectable text or becomes part of an image — see "What Compression Actually Changes" above.
Will my compressed PDF still have selectable, searchable text?
No, not with OxygenPDF's compressor. It rebuilds every page as a rendered image regardless of preset, so words that were selectable and searchable in the original become pixels in the output. Keep the original alongside the compressed copy if you need a searchable version later.
What DPI should I use?
150 DPI is enough for anything read on a screen. 200-300 DPI holds up for most printing. Beyond that is really an archival decision — the Library of Congress's own preservation guidelines put text and manuscript digitization at 300-400 ppi, and reserve 400-600 ppi for rare or fragile originals, not a blanket "as high as possible."
Can I compress a PDF that has a password?
Yes. Upload it, enter the password when the tool asks for it, and compression runs the same as it would on an unprotected file — there's no need to remove the password first.
Why didn't my file get smaller, or why did it get bigger?
Because compression rasterizes every page, a PDF that's already small and mostly text can produce output that's the same size as, or larger than, the original — a rendered image of a sparse text page frequently takes more bytes than the vector text it replaced. The tool will tell you directly when this happens rather than silently handing back a bigger file.
What if the file won't open, or looks corrupted, after compressing?
That shouldn't happen under normal use, but if a file does come out damaged, Repair PDF re-parses and rebuilds a PDF's internal structure and can often recover a file that another step mishandled.
Compress your PDF here, entirely in your browser — nothing you upload ever leaves your device.
Rohman

