PDF Compressor

Compress a PDF in your browser — and know in advance whether it will work

Drop a PDF into the box above and press Compress PDF. The tool rebuilds the document structurally — copying the pages into a clean file and dropping everything that is no longer referenced — then shows you the original size, the new size, and the percentage saved, with a download link for the result. If the file did not get smaller, it says No reduction rather than pretending otherwise.

Read that last sentence twice, because it is the honest centre of this page. This is a structural optimiser, not an image re–encoder. It will not touch the pixels inside your pages. On some PDFs that produces a satisfying drop; on others — scans in particular — it produces almost nothing, and no amount of clicking will change that. The rest of this page explains how to tell which file you have before you waste time.

Everything happens inside the browser tab. The file is read with the browser's file API, rewritten by a JavaScript PDF library loaded with the page, and offered back as a local download. There is no upload: no request carries your document anywhere, so there is no copy on a server to be retained, scanned, or deleted later. Once the page has loaded you can go offline and it still works. For the invoices, medical letters, passports, and signed agreements that make up most "this file is too big to email" situations, that is the difference between a tool you can use at work and one you cannot.

Why your PDF is the size it is

People assume PDF size tracks page count. It does not — it tracks what is embedded. A 200–page text document can be smaller than a 2–page scan. Four things account for nearly all of the bytes:

The two rows marked yes are this tool's entire territory. That territory is not always small: PDFs accumulate junk. Every incremental save appends a revision without removing what it replaced, so a document that has been through several rounds of edits, comments, and re–saves can carry a surprising amount of unreachable material. Rebuilding the file writes only the objects the pages actually reach, and the rest evaporates.

What the rebuild actually removes

• Unreferenced objects — deleted pages, superseded revisions, leftovers from editing tools that were never garbage–collected.
• Document metadata — author, subject, keywords, producer strings, XMP packets. The title is deliberately carried across; the rest is not. If your workflow depends on those fields, note that they will be gone.
• Stale cross–reference tables from incremental saves, replaced by a single clean table.

What it deliberately does not do

• Does not re–encode images. No downsampling, no JPEG quality reduction, no colour–depth changes. Every image comes out byte–identical to the way it went in.
• Does not subset or remove fonts. Embedded typefaces stay embedded, so the document still renders correctly on a machine that does not have them.
• Does not flatten or rasterise pages. Text stays selectable and searchable.
• Does not convert colour to greyscale, remove annotations, or strip attachments.
• Does not accept a target size or a quality slider. There is one operation, and it is lossless.

The upside of that list is the guarantee it buys you: the compression here is lossless as far as page content is concerned. Nothing is blurred, no text is smeared, no signature turns to mush. You will never open the output and find it degraded. The trade is that when the bytes are in the pixels, there is nothing to give back.

Text–native PDFs versus scanned PDFs

This single distinction predicts your result better than anything else, and you can test it in five seconds: open the file and try to select a sentence with your cursor.

If the text highlights word by word, the document is text–native — exported from Word, a browser, an accounting package, a LaTeX build. Its size is mostly structure and fonts, and a structural rebuild has real work to do. Documents that have been edited repeatedly, exported from a heavyweight design application, or generated by a reporting system that leaves debris behind tend to give up the most.

If instead your cursor draws a selection box over the whole page, or a faint text layer highlights in blocks that do not match the visible words, you have a scan. A scanner produces one image per sheet — a compressed bitmap of the paper — and optionally an invisible OCR text layer floated on top for searching. The images are already compressed by the scanner, typically as JPEG or a bilevel format like JBIG2 or CCITT Group 4. A structural rebuild of a scan generally recovers close to nothing, because there was never any structural waste to speak of: the bitmaps were the file.

Seeing No reduction is not a failure of the tool. It is a correct measurement telling you that this file has no structural fat, and that if you need it smaller you must accept a loss of image quality somewhere. Some files even come out marginally larger, because a single clean cross–reference table and fully rewritten object structure can outweigh the junk removed in an already–tidy document. The result panel reports that plainly instead of hiding it — keep whichever copy is smaller.

The email attachment limit, which is why you are probably here

Nearly every PDF compression session starts with a bounced message or a refused upload. Two things are worth knowing before you start fighting the file.

First, the number you must beat is not the number in the mail client's help page. Attachments are encoded for transport, which inflates them by roughly a third, and the receiving server's limit applies to the whole encoded message — body, headers, and every attachment together. A file that sits just under a stated ceiling can still be rejected. Aim comfortably below the limit, not just under it. Second, the limit that matters is the recipient's. Your provider accepting the message is only half the trip; a corporate gateway on the other end can be stricter, and government and healthcare portals with their own upload caps are stricter still.

If a lossless rebuild does not get you there, these are the options that actually move a stubborn file, roughly in order of how much you give up:

• Send fewer pages. If the recipient needs the signed page and the schedule, extract those pages and send a small file. This is the highest–value move and the one people skip — it costs no quality at all.
• Re–scan at a lower resolution or in greyscale. Colour at maximum DPI is the usual culprit. Most scanners default far above what a text document needs; a greyscale or black–and–white rescan of a printed page can be dramatically smaller and perfectly readable.
• Re–export from the original source. If the PDF came from a document you still have, export again and choose a smaller–file or web–optimised preset. This almost always beats compressing the PDF afterwards, because the exporter can downsample images intelligently before they are ever embedded.
• Use a tool that re–encodes images. A desktop application or a server–side service can downsample and re–compress the bitmaps. That is genuinely lossy — and, in the server–side case, it means uploading the document, which is the trade this tool exists to avoid.
• Send a link instead of an attachment. Often the correct answer for a large scanned package, and the only one that scales.

Errors and limits

• PDFs only. Anything the browser does not identify as application/pdf is refused with a message. Images and Office documents are not converted.
• Encrypted or password–protected files cannot be read, and you will see a message saying the file may be corrupted or encrypted. Open it in a viewer that accepts the password, save an unprotected copy, then compress. This applies to permissions–only passwords as well as open passwords.
• Corrupted files give the same message. A file that opens in one viewer but not another is usually truncated.
• One file at a time. There is no batch mode and no queue; use Reset between documents.
• Memory is the practical size ceiling. The source and the rebuilt copy are both held in the tab, so an extremely large scan can exhaust a browser tab, particularly on a phone.
• The download is named after your file with _compressed appended.
• Encryption is not re–applied. Since encrypted files cannot be loaded in the first place, the output is always an unprotected PDF.

Is anything lost?

Visually, no — page content is copied, never re–rendered, so text, images, and vectors are identical. What you lose is document metadata other than the title, plus any structure that was already unreachable. If you need author and keyword fields preserved, note them before compressing and set them again afterwards.

Can I run it twice for more savings?

No. The first pass removes what there is to remove; a second pass on the output has nothing left to find. If one pass did not get you where you need to be, the bytes are in the images, and the list above is your route.

Why do online compressors claim much larger reductions?

Because they re–encode the images — downsampling to a lower DPI and re–compressing at reduced quality — on a server, after you upload the document to it. Those reductions are real and so is the quality loss, which shows up first in small type and fine lines on scans. Different trade, made somewhere else, with your file in someone else's hands.