Compress PDF

Open two PDFs side by side — a one-page invoice and a one-page scanned receipt — and they can look almost identical on screen. Check the file size, though, and the invoice might be 40 kilobytes while the receipt is 4 megabytes: a hundred times larger for a page with less actual content on it. That gap isn't random, and understanding where it comes from is the fastest way to understand what "compressing a PDF" really does, and why it works dramatically better on some files than others. It's also the fastest way to stop guessing at a slider and start making a deliberate choice about it.

This guide covers what actually takes up space inside a PDF, the different techniques compression tools use, how to pick a setting that fits your specific document, and honest guidance on what to expect from a browser-based, rasterization-based compressor like the one on this page — including the one real trade-off worth knowing about before you use it on a text-heavy file.

What's Actually Inside a PDF File

A PDF is a container format — it bundles several different kinds of content together, and each kind behaves completely differently when it comes to file size:

• Text and fonts. Actual typed text is stored as tiny instructions ("draw this character, at this position, in this font") rather than pixels. A page of pure text is typically a handful of kilobytes, embedded fonts included.
• Vector graphics. Lines, shapes, and simple diagrams are stored as mathematical paths, similarly lightweight regardless of how large they appear on the page.
• Embedded raster images. Photos, scans, and screenshots are stored as actual pixel grids. This is where the overwhelming majority of PDF file size usually comes from — a single high-resolution photo can outweigh hundreds of pages of text.
• Structural overhead. Metadata, embedded thumbnails, cross-reference tables, and sometimes leftover revision history from whatever software created the file. Usually small, but it adds up in files that have been edited and re-saved many times.

A document exported directly from Word or Google Docs is almost entirely the first two categories — light, and hard to shrink much further because there isn't much weight to remove in the first place. A document produced by scanning a physical page, or photographing it with a phone, is almost entirely the third category — heavy, and usually very compressible, because camera and scanner output is far higher resolution than a printed page actually needs to look sharp on screen.

The Main Compression Techniques, Explained

"Compress this PDF" can mean several genuinely different operations under the hood. Knowing which one a tool uses explains a lot about what you'll get back.

Image downsampling and re-encoding

The most common technique for image-heavy files: existing embedded images are reduced in resolution and re-saved at a lower quality setting, while everything else in the document — text, fonts, vector graphics, page structure — is left completely untouched. This is the ideal approach when a PDF's size comes from its images, since it targets exactly the part of the file that's actually heavy.

Rasterization (full-page re-rendering)

A different approach: instead of touching only the embedded images, every page is rendered as a whole into a single image, then that image is compressed and reassembled into a new PDF. This is the technique this tool uses, and it's worth being direct about the trade-off: it's simpler to implement safely inside a browser without a server, and it produces very aggressive, predictable size reductions — but any selectable text on the page becomes part of the flattened image too, and is no longer selectable, searchable, or copyable afterward. For a scanned document, there was no selectable text to lose in the first place, so this is a clean win. For a document exported from a word processor, it's a real trade-off, which is why this tool now checks for meaningful text content and warns you before compressing, rather than letting it happen as a surprise.

Font subsetting

Embedded fonts sometimes include every character and weight the typeface offers, even if the document only uses a handful of letters from it. Font subsetting strips a font down to only the glyphs actually used in the document. It's a smaller win than image work, but on text-heavy, font-rich documents it can meaningfully help.

Structural cleanup

Removing unused objects, flattening redundant layers, stripping editing history and thumbnails, and re-compressing the document's internal data streams more efficiently. This is a lossless pass — nothing visual changes — and it's usually the first thing a well-built compressor does before touching images at all, since it's free size reduction with zero quality trade-off.

Choosing the Right Quality Setting

The slider on this tool moves along a single trade-off: smaller file size against sharper detail. Where to land on it depends entirely on what the document is for and who's going to read it.

When in doubt, compress once at a middle setting, open the result, and zoom in on the densest part of the page — a paragraph of small text or a detailed photo. If it still reads clearly at the zoom level you'd realistically view it at, the setting was fine. If not, undo and try one notch higher rather than guessing blind.

Typed Documents vs. Scanned Documents

This is the single biggest factor in whether rasterization-based compression — what this tool does — is the right fit for a given file.

If the PDF was exported from software — Word, Google Docs, Excel, a web page, design software — the text is stored as real, selectable text. Rasterizing it trades that away for size. If you'll need to copy text out of the document later, search within it, or have it read aloud by accessibility software, that's worth knowing before you compress, not after. A text-heavy file also usually doesn't need this kind of aggressive compression in the first place — it's rarely large to begin with.

If the PDF came from a scanner or a phone camera — a signed contract, a receipt, a photographed whiteboard — there's no selectable text layer to lose. The entire page is already effectively one big image; rasterizing and re-compressing it is simply doing directly what the file already was, just at a size that actually matches what the content needs.

If you're not sure which category your file falls into, this tool checks for you: after you select a file, it samples the first few pages for real text content and shows a warning before you compress if it finds meaningful selectable text. No warning means the tool didn't detect a text layer worth preserving, and compressing is very unlikely to cost you anything you had.

A Quick Primer on Resolution and DPI

Most of the "why is this file so big" mystery comes down to one number most people never think about: DPI, or dots per inch — how many pixels are packed into each inch of the page when it was scanned or rendered.

A modern phone camera or scanner will often default to 300 DPI or higher, sometimes considerably more. That's a genuinely useful resolution for a photograph you might crop and zoom into later. For a page of text or a simple form that will only ever be viewed on a screen or printed at standard size, it's substantial overkill — the human eye can't resolve the difference between 300 DPI and 150 DPI on a typical printed page, let alone on a phone or laptop screen, which typically display well under 150 DPI worth of visible detail to begin with.

This is exactly the gap a compressor exploits. Downscaling a 300 DPI scan to something closer to 150 DPI cuts the pixel count — and therefore the file size — dramatically, often to a quarter of the original or less, well before the image starts looking visibly softer to the eye. Past a certain point, though, the curve flips: keep pushing resolution down and quality drops fast, because there's no longer enough pixel data to represent fine details like small text or thin lines cleanly. The quality slider on this tool is essentially moving along that same curve — the useful range is the flat part before quality collapses, and the goal is landing as far along it as possible without crossing into the steep part.

Compression Needs Look Different Around the World

File size limits and connectivity constraints vary enormously depending on where you're uploading from and to, which is part of why "just compress it a bit" isn't always a specific enough goal.

In regions where mobile data is billed by the megabyte rather than offered as an unlimited plan — large parts of South Asia, Sub-Saharan Africa, and Latin America among others — the cost of uploading an uncompressed 8MB scan versus a compressed 400KB version isn't just about speed, it's a real, measurable cost difference on a monthly data bill. In places with consistently fast, cheap fibre connections, the same file size difference might only ever be felt as a couple of seconds of upload time. Neither situation is wrong to optimize for, but they call for different defaults: aggressive compression as standard practice in the first case, and compression mainly as a targeted fix for specific size limits in the second.

Because this tool processes everything locally rather than uploading to a server, the compression step itself costs no data at all regardless of which situation applies — the only network use is loading the page once. What you do with the compressed file afterward is where connectivity and cost start to matter again, which is exactly why getting the file small in the first place is worth the extra step.

How JPEG Compression Actually Degrades an Image

The rendering-and-recompression method this tool uses relies on JPEG encoding, the same format behind almost every photo taken on a phone. Understanding roughly how JPEG degrades an image makes it much easier to predict what a given quality setting will actually look like, rather than treating the slider as a black box.

JPEG works by dividing an image into small blocks and discarding detail the human eye is statistically less likely to notice — subtle colour gradients more than sharp edges, smooth areas more than fine texture. At moderate compression, this trade-off is close to invisible. Push it further and two tell-tale artifacts start to appear: soft, blocky squares in areas that should be smooth (like a plain background or a scanned page's white space), and "ringing" — a slight ghosting or haloing right around sharp edges, most noticeable around small text, where a character's edges start to look faintly smudged rather than crisp.

This is precisely why small text is the first thing to suffer as compression increases, and why a document dense with fine print needs a noticeably higher quality setting than one with large headings and generous white space, even at the same target file size. If you zoom into a compressed result and see this kind of soft blockiness specifically around text, that's the signal to back off one notch on the slider rather than pushing further.

Why Your PDF Isn't Getting Much Smaller

A handful of specific situations account for most "compression didn't do much" cases:

• The file is already mostly text. If there's very little embedded image data to begin with, there's very little for image compression to remove — a 60KB text document compressing down to 55KB is compression working correctly, not failing.
• The images were already compressed once. A PDF built from JPEGs that were already heavily compressed won't shrink much further — most of the easy gains were already taken the first time.
• The page count is doing the work, not resolution. A 200-page document at a modest resolution can outweigh a 5-page document at very high resolution. In that case, the lever that actually helps is fewer pages, not a lower quality setting.
• The quality setting was already close to the top. Near the "better quality" end of the slider, the algorithm intentionally preserves most of the original detail, which means it also preserves most of the original size.

If none of these explain it, try the opposite end of the slider from wherever you started, as a diagnostic — a large jump in size between the two ends confirms images are the main weight and a middle setting will land somewhere useful; almost no difference between the two ends confirms the file simply doesn't have much compressible weight in it, and no setting on this slider is going to change that fundamentally.

Common Size Targets, and Why They Exist

Compression targets aren't arbitrary — they usually trace back to a real constraint somewhere in the pipeline the file is headed toward.

If you have a specific number to hit rather than "as small as reasonably possible," start near the middle of the slider, check the result, and adjust one direction or the other — the live size estimate updates as you move the slider, so you can usually land on target in two or three tries without repeatedly running the full compression.

Working Through Several Files at Once

There's no batch mode here — each file goes through the upload area on its own — but a consistent routine makes working through a stack of documents fast in practice. Pick one quality setting on the first file, check that the result holds up at the zoom level you actually need, and reuse that exact setting for the rest of the batch rather than re-adjusting the slider from scratch on every single file. Most stacks of similar documents — a folder of scanned receipts, a set of signed forms — compress predictably at the same setting, so the first file effectively becomes a test case for the rest.

Since everything happens locally, there's no cooldown, daily cap, or queue to wait through between files the way there sometimes is on server-based tools that meter usage to control their own infrastructure costs — the page is ready for the next file the moment you click "Compress Another File."

Getting the Best Result From This Tool

1. Check the file type first. If it's a scan or photo-based document, compress freely. If the warning banner appears after you select it, decide whether keeping selectable text matters more than the size reduction for this particular file.
2. Start in the middle of the slider, not at either extreme, and read the live size estimate before committing to a full pass.
3. Compress once, inspect the result closely — not just the file size, but the actual legibility of the densest page — before deciding you're done.
4. Keep the original file until you're sure you won't need the full-quality version again. Compression here is lossy and one-way.
5. For very large or very long documents, consider splitting into smaller sections first if the whole file feels sluggish to process — everything runs on your own device's memory rather than a server.

Frequently Asked Questions