PDF File Size Not Reducing? What Is Actually Happening

You dropped a PDF into a compressor, waited, downloaded the result, and the file size barely moved. A 4.2 MB document came back as 4.1 MB. Nothing looks broken, no error appeared, and yet the thing you wanted did not happen.

The reason this is confusing is that “compress” describes two completely different operations that happen to share a button. One rewrites the file’s internal bookkeeping and cannot touch your content. The other throws away picture detail on purpose. A PDF file size not reducing after a compress run almost always means you asked for the first one.

The usual cause: you picked the lossless setting

The Low setting on our PDF compressor is lossless. It loads the document, then writes it back out with object-stream compression switched on. Object streams are a PDF feature that packs many small internal objects — fonts references, page dictionaries, annotation records — into a single compressed block instead of storing each one separately.

That helps on a PDF assembled by older software, or one built by concatenating other files, where the internal structure is verbose. On such a file you will see something in the region of 5 to 15 percent off.

Here is the catch. Every mainstream PDF generator already does this. Export from Microsoft Word, Google Docs, Apple Pages, InDesign, LaTeX, or your browser’s print-to-PDF, and the file arrives with its object streams already compressed. Running a lossless pass over it is like re-zipping a zip file: the operation completes, the output is valid, and the size is essentially unchanged.

A near-zero reduction on Low is the correct result for a modern PDF. The tool is not failing. It is doing exactly what lossless means, which is that nothing about your pages is allowed to change.

What the three levels actually do

These are the real parameters, not marketing tiers:

• Low — no rasterisation. The document is re-saved through pdf-lib with useObjectStreams enabled. Text stays selectable. Typical reduction 5–15 percent, and often close to zero on a already-optimised file.
• Medium — every page is re-rendered at 144 DPI and stored as a JPEG at quality 0.65, then embedded into a fresh PDF. Typical reduction 50–70 percent.
• High — every page is re-rendered at 96 DPI and stored as a JPEG at quality 0.45. Typical reduction 70–85 percent.

Notice what changes between Medium and High: the DPI goes down, from 144 to 96. Fewer pixels per inch means a smaller image, which is where most of the extra saving comes from. The JPEG quality drops as well, from 0.65 to 0.45, which is the second lever.

Both of those levels rebuild your document as a sequence of pictures. That is the mechanism, and it is also the entire tradeoff — more on that below.

When a PDF gets bigger instead of smaller

This surprises people, and it has two distinct causes.

Cause one: a low-DPI scan

A scanned document is already a stack of JPEGs wrapped in a PDF. Suppose your scanner produced pages at 100 DPI. Medium renders each page at 144 DPI, which means the tool is upscaling — generating roughly twice as many pixels as the original contained — and then JPEG-encoding that larger image a second time.

More pixels, plus a second lossy encode on top of an already-lossy source, can easily exceed the original file size. If you are compressing a scan and the output grew, drop to High. At 96 DPI you are downscaling rather than upscaling, and the result will be smaller.

Cause two: a vector-heavy document

Charts, diagrams, CAD exports and slide decks are stored as vector drawing instructions: move to this coordinate, stroke a line of this width, fill this path. That representation is compact. A full page of charts might occupy a few kilobytes.

Rasterising that page at 144 DPI replaces a few kilobytes of instructions with a full-page bitmap that could run to hundreds of kilobytes. For vector-heavy files, Low is the honest choice even though its reduction number looks unimpressive, because there is very little redundancy to remove in the first place.

Which level to pick, by document type

1. Text document from Word, Docs or LaTeX, needs to stay searchable — use Low and accept the small reduction. If it is still too large, the size is coming from embedded images, and the fix is to shrink those in the source document before exporting.
2. Text document, email attachment limit, searchability not needed — Medium. This is the case where the 50–70 percent figure actually lands.
3. High-DPI scan, 300 DPI or above — Medium first. The downscale to 144 DPI is a genuine reduction and stays readable on screen.
4. Low-DPI scan, under 150 DPI — High. Medium will upscale it and may grow the file.
5. Charts, diagrams, CAD, slide decks — Low. Rasterising vectors usually costs more than it saves.
6. Photo-heavy portfolio or brochure — High. Photographs are exactly the content JPEG was designed for, and the quality drop at 0.45 is least noticeable on continuous-tone images.

The cost nobody mentions: your text stops being text

When Medium or High rasterises a page, the characters stop existing as characters. They become dark pixels arranged in the shape of letters. The document still looks identical on screen, which is precisely why this catches people out weeks later.

What breaks:

• Selecting and copying text
• Find-in-document search, in any reader
• Screen readers, which have nothing to announce
• Any downstream text extraction, indexing or data pipeline
• Full-text search in the systems you later upload the file to

Before you compress a contract, a thesis, a tax filing or anything that will be searched, archived or read aloud, consider whether losing the text layer is acceptable. If it is not, Low is your only option, and the real fix lives upstream in the source document.

If you have already flattened a file and need the text back, running OCR will reconstruct a text layer by recognising the letter shapes. That is a reasonable recovery, though OCR output is a best-effort transcription rather than the original characters, so it will not be perfect on unusual fonts or dense tables.

What reduction to expect, and why it varies so much

The published ranges — 5–15 percent for Low, 50–70 for Medium, 70–85 for High — are wide because the outcome depends almost entirely on what is inside your pages, not on the setting alone. Two files of identical size can behave completely differently.

Take a 4 MB PDF. If that 4 MB is a 40-page contract exported from Word, almost all of the weight is embedded font data and the text stream. Low will shave a fraction of a percent, because Word already packed it. Medium will land near the top of its range, because rendering a page of black text on white to a 144 DPI JPEG produces a very compressible image — large flat areas of white are the easiest thing a JPEG encoder ever has to deal with.

Now take a different 4 MB PDF that is eight pages of product photography. The photos are already JPEG-compressed inside the file. Medium re-encodes them at quality 0.65, which will help, but the ceiling is much lower because you are compressing something that was already compressed once. Expect the bottom of the range rather than the top, and expect visible artefacts in gradients and skin tones before you see a dramatic size drop.

The general rule: the more uniform your pages are, the better compression works. Text and line art compress enormously. Photographs compress modestly. Content that has already been through a lossy encoder compresses least of all, and degrades fastest when you push it.

When even High is not enough

If you have run High and the file is still over the limit you are trying to hit, compression has given you what it has. At that point the lever is the document itself rather than its encoding.

1. Remove pages you do not need. Size scales almost linearly with page count on image-heavy documents. Dropping an appendix often beats any encoder setting. Use delete pages or extract just the pages you need.
2. Split it into parts. Many upload forms cap each file rather than the total. Two 3 MB files often pass where one 6 MB file fails. Split the PDF at a sensible chapter boundary.
3. Fix the source. If the PDF came from a document you still have, resize the images inside it to the dimensions they are actually displayed at and re-export. A 4000-pixel-wide photo placed in a 600-pixel box carries roughly forty times the data it needs.

The third option is the one most people skip and the one that produces the best result, because it removes the excess before it ever reaches the PDF rather than trying to encode around it afterwards.

Everything here runs on your own machine

The compressor uses pdf.js to render pages and pdf-lib to rebuild the document, both executing in your browser tab. Your file is read from your own disk into memory, transformed there, and written back out as a download. It is not transmitted anywhere.

The practical test: load the page, disconnect from the network, and compress a file. It still works. That matters for salary slips, bank statements, medical records, signed agreements and identity documents — the exact category of file people most often need to shrink for an upload form, and least want to hand to a third-party server on the way.

A quick way to diagnose your own file

1. Run Low first. Note the percentage. If it is close to zero, your PDF was already optimised, which tells you the size is in the page content rather than the file structure.
2. Open the PDF and try to select a sentence. If you can, it is a text document. If you cannot, it is a scan or already-flattened, and the size is image data.
3. Text document that will not shrink on Low: the weight is in embedded images. Medium is the lever, or fix the images in the source.
4. Scan: check whether it looks sharp when you zoom to 200 percent. Sharp suggests high DPI, so use Medium. Soft or blocky suggests low DPI, so use High.

Working through those four checks takes under a minute and tells you which setting your specific document needs, rather than guessing and re-running.