Your PDF Isn't Big Because of the Text: Compressing PDFs Entirely in the Browser

Every developer who has built a file tool has heard the same user complaint: "Your compressor ruined my document." And every user who has uploaded a national ID card to a random compression website has felt the same quiet worry: "Where did my file just go?"

Both problems have the same root cause — most PDF compressors treat a PDF like a photograph. They render each page to an image, squeeze the image, and hand you back a file that looks like a photocopy of a photocopy. And they do it on a server, because that's how it's always been done.

I build BrightFreeTools, a set of free file tools that run 100% in the browser. This post is about what I learned taking PDF compression client-side: how a PDF is actually put together, where the bytes really live, and the quality floors that stop you from destroying someone's certificate in the name of a smaller file.

A PDF is not a picture of pages

A PDF file is a collection of objects. The parts that matter for file size:

• Content streams — the drawing instructions for each page, including text shown with embedded fonts. This is astonishingly cheap. A dense page of typed text is a few kilobytes.
• Font programs — embedded fonts, usually already subsetted in anything exported from a word processor.
• Image XObjects — every photo, scan and screenshot stored inside the file, usually as JPEG (DCTDecode) or lossless (FlateDecode) data. This is where the megabytes live.

One phone photo of a document page is typically 2–4 MB. A five-page scan can be a 15 MB PDF whose actual text content would fit in a tweet. When someone says "my PDF is too large for the form," they almost always mean "my PDF contains uncompressed camera photos."

That gives you the golden rule of quality-preserving compression:

Never touch the content streams. Only re-encode the images, and re-pack the streams losslessly.

Flatten pages to images and you destroy selectable text, inflate some files, and blur everything. Leave text as text and the document stays sharp at any zoom, forever.

The three levers, in order

1. Recompress the images against a DPI floor

An image inside a PDF has a natural display size (its placed width and height on the page) and a pixel count. The ratio is its effective DPI. A 3000×4000 phone photo placed across an A4 page is running at ~400 DPI — far beyond what eyes or office printers can use.

Downscaling images to a floor of about 100 DPI and re-encoding as JPEG at a clean quality setting removes the overwhelming majority of bytes in photo-heavy PDFs. In testing, a one-page form with a large photo went from 1 MB to 46 KB, with the photo still clearly readable.

2. Convert text-heavy images to bitonal

Scans of documents are the interesting case. A grayscale or color scan of a text page wastes bytes storing "slightly off-white" for every pixel. Convert that image to pure black and white at around 150 DPI and two things happen: the data collapses (1-bit pixels compress brutally well), and the letters actually look cleaner than in the gray scan, because the thresholding removes shadows and bleed-through.

A five-page scanned document: 2.7 MB → 260 KB in color-preserving mode, 208 KB in black and white. Every line readable.

The catch: you have to decide which images are "text pages" and which are photographs. Get it wrong and someone's photo turns into a photocopied mess. My rule of thumb: analyze the image's color distribution — near-bimodal, low-color images are documents; rich continuous-tone images are photos. Then, when in doubt, keep color.

3. Re-pack everything losslessly

Object streams and content streams can be recompressed with Flate, unused objects dropped, and metadata stripped. This is free size reduction with zero visual change — usually a few percent, occasionally much more on files produced by sloppy generators.

Exact sizes: when the form says 200 KB, it means 200 KB

The hardest variant of this problem isn't "as small as possible." It's the government or exam form that rejects anything above exactly 100 KB or 200 KB. Users don't want the smallest file; they want the largest file that still fits, because every extra kilobyte is quality.

That's an optimization loop: try settings, measure output, adjust image scale/quality up or down, converge just under the target. Binary-search behavior, a handful of iterations, done in seconds client-side. It's why I built Compress PDF to an exact size as a separate tool from the extreme compressor — the goals sound similar but the algorithms are pointed in opposite directions.

Quality floors, or: know when to stop

Aggressive compression needs a hard floor, or you will eventually mangle a document someone needed for a visa application. Mine are:

• Photos never go below ~100 DPI.
• Text pages never go below ~150 DPI bitonal.
• If the result isn't at least ~5% smaller than the input, return the original untouched and say so. A typed, picture-free PDF is already near its floor, and pretending otherwise just degrades it.

Why do this in the browser at all?

Three reasons:

1. Privacy. The files people compress are marksheets, ID cards, bank statements. If the processing happens in a Web Worker on their device, the file never crosses the network. There's no server copy to leak, log, or subpoena.
2. Cost. Zero bandwidth, zero compute bill. A static site can serve a tool like this to a million users for pocket change.
3. Speed. No upload wait on a slow connection — which, for many of the users who need exact-KB compression for application forms, is the normal kind of connection.

The trade-off is real: you're bounded by the device's CPU and memory, and very large files (hundreds of pages, hundreds of MB) will strain a low-end phone. For the 1–20 page documents that dominate real-world usage, the browser is more than enough.

Try it

The tools are free, with no sign-up and no upload:

• Extreme Compress PDF — smallest readable file, automatically
• Compress PDF to 100 KB / 200 KB / any size — for forms with a hard limit

If you've built document tooling on the web, I'd genuinely like to compare notes: what DPI floors do you use, and how do you classify an image as "document" vs "photo"? That classification problem turned out to be the whole game.

Hasibul Mawla is an Android and web developer from Dhaka and the founder of BrightFreeTools.