Compress PDF — Reduce PDF File Size Online for Free

A 40 MB scan won't attach to an email, a presentation won't upload to a form, a contract with embedded photos weighs as much as a photo archive. Most of the time what keeps such a PDF from slimming down is the images inside it — scans and photos at full resolution. The "Compress" tool in pdfredX repacks pages at the quality you choose, right in the browser: you move one slider, see the resulting size and download a lighter file. Nothing is uploaded to a server.

Step 01. Load the PDF

Open pdfredx.com and drag a PDF into the drop area — or pick it through your file browser. The file is read locally: PDF.js renders the pages inside the tab, not a single byte goes to a remote machine. A document that's already loaded can be sent straight to compression.

Step 02. Choose the compression level

Open the "Compress" panel — there are three settings here:

• Quality slider. Sets the JPEG quality for the images inside the pages. 90–95% is a barely noticeable loss with the file several times smaller; 60–70% is maximum savings for drafts and attachments where only the text matters. The value is shown right on the slider as a percentage.
• ☑ Limit to 1500 px. Reduces page resolution to 1500 px on the long side. That's plenty for on-screen reading and A4 printing, and the "weight" drops the most here — it is usually the excess resolution of scans that bloats a file.
• ☑ Clean metadata. Strips the document's service information so nothing extra is carried into the output file.

Balance it to the task: for sending to an agency — compress harder; for archiving an important document — keep the quality higher.

Step 03. Download the compressed PDF

Press "Compress PDF". The app walks the pages, repacks each one at the chosen quality and assembles a new file through jsPDF. After assembly you'll see the result — by what percentage the size shrank and how many megabytes it became. The finished document downloads straight from the browser. Free, no sign-up, no server queue.

How it works under the hood

Compression runs along a raster path. Each page is already an image (PDF.js drew it to a Canvas on load). The compressImageUrl function draws that image onto a new canvas of the required size and re-exports it to JPEG at the chosen quality:

const scale = maxPx ? Math.min(1, maxPx / Math.max(origW, origH)) : 1; // downscale to 1500px
c.width  = Math.round(origW * scale);
c.height = Math.round(origH * scale);
ctx.drawImage(img, 0, 0, c.width, c.height);
c.toDataURL('image/jpeg', quality);                                    // repack at quality

Then jsPDF assembles the pages into a new document — each one is fit into an A4 sheet with proportions preserved and centered. The output size is compared with the original estimate, and that gives the savings percentage.

Known limitations

Lossy compression. Lowering JPEG quality and resolution are irreversible operations. Small text on scans may soften under heavy compression. If the document matters, start at 90% and lower it while watching the result.

The text layer becomes raster. The pipeline works with page images, so in the compressed file the text is part of the picture — it cannot be selected or copied. For documents that need live text, keep that in mind.

Maximum benefit is on "heavy" scans. A file made mostly of photos and scans compresses a lot. A document with little graphics to begin with won't shrink noticeably — there is almost nothing in it to compress.

Need the opposite — combine several documents into one? That is the Merge PDF tool.

Try it right now — pdfredx.com, no registration, your files stay with you.

A familiar wall: the email won't send — "attachment size exceeded"; the portal form won't accept your certificate — "file too large"; the scan of a contract won't fit into the support chat. Email services usually cap attachments at 20–25 MB; government and banking forms are often stricter still. And almost always it's a confidential document: a passport scan, a certificate, a statement, a contract. Let's look at how to shrink such a file and why it's worth doing locally rather than through the first online compressor you find.

Why the file won't fit and what you're usually told to do

It isn't the letters that bloat a PDF — it's the images: scans and photos at full resolution easily add up to tens of megabytes over a few pages. To fit the limit, the file has to be repacked — the quality and resolution of the images inside lowered.

The typical advice is "upload the PDF to an online compressor." And here's the catch: to compress the document, an ordinary service asks you to send it in full to its server. For an operation that boils down to re-saving images, your passport or bank statement travels to someone else's machine.

Where the document goes on server-side compressors

When you upload a PDF to a typical online shrinker, the file travels in full to a remote machine. From there it follows the service's policy, which few people ever read:

• the document is stored in a contractor's temporary storage (AWS, GCP, Azure);
• it is processed on someone else's server;
• it is kept from a few hours to several days "for reliability";
• it is logged together with metadata — IP, time, file name and size.

The irony: you shrink the file to send it to one agency over a secure channel, yet on the way it gets to sit on the server of an unrelated compressor service. For documents with personal data, that is exactly the risk you were trying to avoid.

The local alternative: compression right in the browser

pdfredX compresses a PDF without uploading it anywhere. That is a consequence of the architecture, and you can verify it.

The file is read locally. PDF.js opens the document in the tab and draws the pages to a Canvas. There is no network request carrying your file.

Repacking happens in the tab's memory. Lowering JPEG quality, downscaling to 1500 px, cleaning metadata, assembling a new PDF through jsPDF — all of these are operations on data that is already loaded. Nothing is sent anywhere.

The finished file is built on the client. The compressed PDF is formed right in the tab and handed to the browser for download — into your "Downloads" folder, not to a server and back.

It works offline. Load the file, turn off the internet and compress the document — everything keeps working. The network is only needed to load the app once.

In practice: open the "Compress" panel, dial in the quality with the slider (for attachments, 70–80% plus the 1500 px limit is usually enough), download the file and check that it fits the limit. If it doesn't — lower the quality one more step.

What we cannot guarantee — an honest disclaimer

Client-side processing protects a document from being sent to external servers, but it is not a shield against every threat, and promising otherwise would be dishonest.

Malware or a keylogger on the device. If the machine is compromised, a program can read files off the disk bypassing the browser entirely.

Browser extensions with broad permissions. An extension with "read data on all sites" access can, in theory, see the tab's contents. For sensitive documents, work in a profile without third-party extensions or in a private window.

The saved file stays on your disk. If the device is not protected by encryption, confidential files can be read by third parties with physical access.

We provide isolation at the level of the browser tab. The rest is on the user's side.

Shrink a document under the limit without uploading it to a server — pdfredx.com, free, no registration.

You can compress a PDF "the grown-up way" on a server: parse the structure, walk the image streams, downsample them, optionally repack losslessly with FlateDecode, reassemble the document. In the browser, with no backend and no file upload, the set of constraints is different — and the architectural choice is not obvious. Let's break down how the compress tool in pdfredX is built: why raster re-encoding through Canvas instead of structural optimization, how the savings are computed, and where the boundaries of the approach run.

The architectural challenge: structural optimization vs. the raster path

How PDFs are compressed "by the book." A classic optimizer works on the file structure: it finds image streams (XObject), lowers their resolution (downsampling), repacks the JPEG objects at a new quality, applies FlateDecode (that same zlib/deflate) losslessly to text and vector streams, cleans duplicate fonts and metadata. It is precise but complex: it needs a full PDF parser and careful work with the binary object graph.

Why pdfredX takes the raster path. The tool is built into the app's shared pipeline, where a page of any document is already reduced to an image: PDF.js drew it to a Canvas back at load time. So compression does not re-parse the PDF structure — it repacks ready-made rasters. The upsides are predictability (if PDF.js showed the page, it will compress) and privacy (parsing and repacking happen in the tab, the file goes nowhere). The price is a raster result: the text layer is not preserved, and compression is lossy. For the typical scenario (heavy scans and photos) that is a justified trade-off: it is the images that make up almost all of the "weight."

The implementation, piece by piece

Repacking a page: Canvas → JPEG

The core of compression is the compressImageUrl function. It draws the page image onto a new canvas (downscaled if needed) and re-exports it to JPEG at the chosen quality:

async function compressImageUrl(url, origW, origH, maxPx, quality) {
  const scale = maxPx ? Math.min(1, maxPx / Math.max(origW, origH)) : 1; // downsampling
  const img = new Image();
  img.src = url;
  // ...onload:
  const c = document.createElement('canvas');
  c.width  = Math.max(1, Math.round(origW * scale));
  c.height = Math.max(1, Math.round(origH * scale));
  const ctx = c.getContext('2d');
  ctx.fillStyle = '#fff';                    // white backing instead of transparency
  ctx.fillRect(0, 0, c.width, c.height);
  ctx.drawImage(img, 0, 0, c.width, c.height);
  return c.toDataURL('image/jpeg', quality); // the single point of loss
}

There are two independent levers here. Downsampling (scale) is turned on by the "Limit to 1500 px" checkbox: if a side exceeds the threshold, the image is physically reduced — and that gives the main savings, because it removes redundant pixels. JPEG quality (quality, 0–1 from the slider) tunes the strength of compression at the same resolution. The white backing is needed because JPEG holds no alpha channel: without it, transparent areas would turn black.

Why JPEG here, not FlateDecode

FlateDecode is lossless compression; on a photographic raster it is nearly useless (deflate barely shrinks a noisy image). The real savings on scans come precisely from lossy JPEG plus a resolution drop. So the raster pipeline picks JPEG: it hits exactly what bloats the file. FlateDecode remains a strong technique for *structural* compression (text, vector), but that is a different, non-raster path.

Assembly and the savings count

The repacked pages are assembled into a new document the same way as in merging: jsPDF, an A4 sheet, orientation by proportions, each page fit with proportions preserved (contain) and centered. Savings are computed by comparing the real output size with an estimate of the original:

let origEstimate = 0;
for (const p of items) origEstimate += Math.ceil(p.editUrl.length * 0.75); // base64 → bytes
// ...after assembly:
const compressedSz = pdf.output('arraybuffer').byteLength;
const savedPct = Math.max(0, Math.round((1 - compressedSz / origEstimate) * 100));

The 0.75 factor turns the length of the base64 dataURL string into an estimate of the byte count (base64 inflates data by about a third). An exact comparison is only possible after assembly — which is why the percentage is shown at the end rather than predicted up front.

Trade-offs and the limits of the approach

Losses are irreversible. Both lowering quality and downscaling cut information away for good. Recompressing an already-compressed file degrades the picture quickly — compress from the original.

Peak memory during processing. Each page briefly holds a decoded bitmap in memory (an A4 sheet at 150 DPI is ~8.7 MB RGBA), a new canvas and the resulting JPEG string. On large bundles a tick() is inserted between heavy steps so the tab doesn't freeze and the progress bar updates.

On "light" documents the benefit is small. If a PDF has almost no raster graphics, there is nothing to repack — the size won't change noticeably.

What's next

A hybrid mode for digital PDFs — keep text and vector as they are (the structural path with FlateDecode) and apply lossy compression only to raster objects. That would deliver "compression without losing text" where the source allows it.

A before/after preview on a single page — judge the quality by eye before processing the whole document, so you don't dial the slider blindly.

Want to test it on your own file — load a heavy scan on pdfredx.com and find the balance of quality and size. No registration, no file upload to a server.