A PDF is a container

A PDF file is a collection of objects: page descriptions, fonts, images, metadata, sometimes attachments and form fields. When you compress a PDF, you're really re-encoding some of those objects. So the first question is always: which objects are big?

In everyday documents, the answer is usually one of these.

1. Images, by a wide margin

A scanned page is a picture of a page. A phone scan saved in full colour at 300 DPI is roughly 2480 × 3508 pixels. Even with JPEG compression, that can be 500 KB to 1 MB per page. Three pages and you're past 2 MB before anything else.

Word documents with pasted photos have the same problem: the original 12-megapixel image is often embedded at full resolution, even if it's displayed as a small thumbnail.

2. Embedded fonts

Fonts are usually small, but some PDFs embed complete font files instead of only the characters used. With several fonts, especially CJK fonts, this can add a few hundred KB.

3. Duplicated or leftover objects

Files that were edited many times, merged from several sources, or exported by certain tools can carry duplicate images, unused objects, or incremental-save history.

4. Things that aren't visible

Thumbnails, metadata, embedded colour profiles, and attachments add a little each.

What compression can fix

Most of the savings come from images: downsampling them to a sensible resolution (150 DPI is plenty for on-screen reading and most form uploads) and re-encoding them at a lower JPEG quality. Font subsetting and removing duplicate or unused objects help on top of that.

A well-behaved compressor searches for the highest quality that still fits your target size, rather than applying one fixed "low/medium/high" setting.

What it can't fix

Compression has a floor. If a 40-page colour scan needs to fit in 100 KB, there may be no quality setting that keeps it readable. At that point, fix the source:

• Rescan at 150–200 DPI instead of 300 or 600.
• Scan text documents in grayscale or black and white. Colour roughly triples the data for no benefit on a printed form.
• Crop to the page. Scanning the whole scanner bed adds empty pixels.
• Split the file if the portal allows several uploads.
• Export, don't print-to-PDF, from Word or Google Docs, and use "minimum size" options where available.

Typical upload targets

Common limits are around 100 KB for ID scans, 200 KB for visa and application forms, 500 KB for strict job portals, and 1–2 MB for general applications. Check the exact number on your form; they vary.

A browser-based option

I built PDFSizeFit for this exact situation. You pick a target such as 100 KB, 200 KB, 500 KB, 1 MB or a custom size, and it keeps the best quality that fits. If the file can't get that small, it says so and gives you the smallest version it could make, instead of quietly producing an unreadable file.

It also merges, splits and reorders pages and converts JPGs to PDF. Processing happens locally in your browser, so documents aren't uploaded to a server, and there's no account.

Compress your PDF at pdfsizefit.com

Here's the thinking behind it.

1. Treat the size limit as the input

Users don't care about a "quality: 0.6" setting. They care about one number: the portal's limit. So the main input is a target (100 KB, 200 KB, 500 KB, 1 MB, 2 MB, or custom), and the output is the measured result size, not an estimate.

2. Not every PDF needs the same treatment

A PDF's weight usually comes from one of two places:

• Text and vector content (exported from Word, etc.). Re-encoding gains little here and can only hurt. These files get repacked only: same content, cleaner structure, visually identical.
• Embedded raster images (scans, photos). This is where the bytes are, and it's where compression actually happens.

Detecting which case you're in first prevents the classic bug of "compression" making a crisp text PDF blurry.

3. Search for the quality instead of guessing it

For image-heavy files, the simplest reliable approach is a search over encoder quality:

// Simplified illustration of a target-size search
async function fitToTarget(pdf, targetBytes) {
  let lo = 0.1, hi = 0.95, best = null;
  for (let i = 0; i < 7; i++) {
    const q = (lo + hi) / 2;
    const out = await recompressImages(pdf, { quality: q });
    if (out.byteLength <= targetBytes) { best = out; lo = q; } // fits, so try higher quality
    else { hi = q; }                                          // too big, so lower quality
  }
  return best; // null means the target isn't reachable at this resolution
}

If quality alone can't reach the target, the next step is lowering image resolution. Rasterizing whole pages is the last resort, and the results screen says when it happened, because it changes what the document is.

4. Be honest when the target is impossible

Some files simply can't hit 100 KB without becoming unreadable. Rather than failing silently or returning a mush of pixels, PDFSizeFit tells the user, and still gives them the smallest version it managed. A clear "this can't get smaller than 340 KB" beats a broken upload at the end of a long form.

5. Keep files on the device

The documents people compress for portals are the sensitive ones: ID proofs, bank statements, certificates. Processing everything client-side means nothing is uploaded, there's no server cost per file, and the privacy claim is something users can check in DevTools.

The trade-off is memory. Files can go up to 100 MB, but big scans depend on the device's free RAM. That's worth saying plainly on the page rather than pretending it doesn't matter.

What else is in the kit

The same in-browser approach powers batch compression (ZIP download), merge, split, page organizing, JPG to PDF and PDF to Word.

Takeaways for anyone building file tools

• Design around the user's real constraint (a size limit), not your encoder's settings.
• Classify the input before transforming it.
• Measure the output, don't estimate it.
• Fail honestly and still return something useful.
• Client-side processing is a feature. Say so, and let people verify it.

Try it: pdfsizefit.com. It's free, with no account. I'd like to hear what files break it.