Skip to content
Compress PDF
English

A compression engine that runs in your tab.

No worker queues, no upload endpoints, no “processing on our servers” copy. Here is exactly what happens to a PDF between the drop and the download.

Try it on your PDF

Step 1

Read and understand the file

The file is read with the browser's File.arrayBuffer() API. Nothing is posted anywhere; the bytes live in the tab's memory.

PDF.js opens the document and counts the pages. A handful of pages spread across the file are sampled for text density. If a sampled page contains almost no characters, the document is probably a scan. If it has plenty, it is text-based. That classification determines whether image recompression or rasterisation is tried first.

The analysis also catches password protection. Encrypted files stop here with a clear message rather than producing a damaged output.

Step 2

Three escalating passes

Each pass is a complete rebuild. The engine measures the result before deciding whether the next, more destructive pass is necessary.

Pass one — structural cleanup

pdf-lib loads the document and rewrites it with object streams enabled. Page thumbnails, orphaned objects and identifying metadata are removed. Fonts, images and page content are untouched, so this pass is effectively lossless.

Lossless

Pass two — image recompression

The engine walks each page's resource dictionary, including images nested inside form XObjects, and finds JPEG image streams. Each one is decoded with createImageBitmap, drawn onto a canvas at a reduced size, and re-encoded at a lower quality.

The new stream replaces the old object in place, so the page layout, text, links and vector art are unchanged. Images with soft masks, CMYK colour spaces, JPX or JBIG2 compression are skipped instead of risking a broken render.

Text preserved

Pass three — rasterisation

When the target is still out of reach — or when the source is a scan — PDF.js renders each page to an offscreen canvas at 36–160 DPI. The JPEGs are assembled into a fresh document with pdf-lib. This flattens text into pixels, so it runs last and the result panel says so.

Last resort

Step 3

Search for the best result that fits

Image settings are walked as a ladder sorted by expected output weight: scale squared multiplied by JPEG quality. The first step that measures under your target wins. If the result is comfortably below the target, the engine tries one step better to give you a sharper file, and keeps whichever fits.

Rasterisation uses a separate ladder from 160 DPI down to 36 DPI. Reducing resolution is the fastest way to shrink a scan, so the ladder trades resolution and JPEG quality together rather than dropping either to an extreme.

The honesty rule: success means outputBytes <= targetBytes, measured on the finished file. If nothing fits, the tool shows the smallest real result and how far above the target it is. It never rounds down, estimates, or labels an overshoot as a success.

Step 4

Why the interface never freezes

Web Worker

PDF parsing and JPEG encoding run in a dedicated worker, so scrolling, selecting and typing stay responsive while a large file is processed.

OffscreenCanvas

Image work happens on an offscreen canvas that does not touch the DOM. Browsers without it fall back to a chunked main-thread path.

Bounded memory

Pages are processed in batches, bitmaps are closed after use, object URLs are revoked, and large files are flagged before they can exhaust a phone’s memory.

What it cannot do

Limits we would rather admit

  • No OCR. Scanned pages stay scanned; the tool cannot make their text searchable.
  • No password decryption. Encrypted PDFs are detected and declined.
  • No signature preservation. Any compression invalidates cryptographic signatures.
  • No JBIG2 or JPX re-encoding. Those images are left untouched to avoid corruption.
  • No guaranteed size reduction. A well-optimised text PDF may shrink only slightly.
  • No cloud processing. If your device runs out of memory, a server will not help.

Engine questions

Deeper answers about how the compressor behaves.

Why does the compressor try several settings instead of one?

Because the relationship between image quality and file size is not linear, and every PDF is different. The engine walks a ladder from high quality to aggressive compression, saves a real PDF at each step, measures it, and stops at the first result that fits your target. That result is the best-looking file that meets the limit.

Why not always rasterise? It produces the smallest files.

Rasterising turns text into pixels. The file gets smaller, but text stops being selectable, links break, and small print blurs. It is offered as a last resort for scans, and the result panel always tells you when it was used.

Does the tool support password-protected PDFs?

Not yet. PDF.js can open an encrypted file with a password, but the library that rebuilds documents cannot re-encrypt the result. Rather than produce a broken file, the tool detects encryption and asks you to remove the password in a PDF reader first.

Why did a text-only PDF barely shrink?

Text and vector graphics are already compact. If 95% of a file is text and fonts, there is very little redundant data to remove. Tools that report huge savings on such files are usually rasterising the pages, which is why this tool reports the method it used.

What about digital signatures?

Any modification invalidates a cryptographic signature. No compression tool can preserve one. Keep the signed original and compress a copy if you need to send a smaller version.

See it work on your own file.

Drop a PDF, pick a target, and watch the measured result.

Compress a PDF