Compress PDF to 100KB, 200KB or 500KB

Which target should you pick — 100KB, 200KB or 500KB?

Don't compress harder than your portal forces you to. Every kilobyte you shave off a scan costs sharpness, so the rule is simple: read the portal's exact limit and pick the loosest target that clears it. These three cover almost every form you'll meet.

When a portal states a range (e.g. 'up to 500KB'), aim for the top of it — over-compressing can trip validators that reject suspiciously tiny files as likely-corrupt.

Can your PDF reach the target? A 10-second reality check

Whether your file fits depends almost entirely on what's inside it. Text and vector graphics are nearly free — a page of typed text costs 10–40KB. Scanned images are what blow the budget: a single page scanned at 300 DPI in colour starts life at 500KB–2MB before any compression. Use this table before you start, so you know whether you're one click away or need the rebuild trick below:

Figures are typical ranges for mixed real-world documents, not guarantees — scan resolution, colour depth and page count dominate.

What the compressor actually does (and never does)

Three levers, applied in order of how little they hurt: strip metadata and dead objects (thumbnails, unused fonts' cruft, editing leftovers — free savings); re-pack the PDF's internal object streams (also free); then downsample and re-encode embedded images, walking resolution and JPEG quality down until the file fits your chosen target. Text and vector content are never rasterised or re-encoded — typed text is identical at any target size, which is why a text PDF at 100KB looks exactly like the original while a scan visibly trades sharpness for size.

That ordering is also why the tool refuses impossible jobs honestly: if your file can't mathematically reach your target without destroying legibility, it says so instead of delivering unreadable soup. When 100KB is out of reach, step up to a 200KB or 500KB target if your portal allows it, or use the rebuild recipe below.

Resumes: the size problem is usually self-inflicted

A resume built in Word, Google Docs or a resume builder and exported to PDF is text plus a little vector layout — 30 to 80KB without any compression at all, well under even a 100KB cap. Resumes blow past upload limits for exactly two reasons: a multi-megapixel headshot pasted at full resolution, or the killer — a printed-and-rescanned document, which turns every page of selectable text into a photograph of text.

So before compressing, fix the source if you can: export to PDF directly instead of scanning a printout, and let the compressor handle the headshot (downsampling a 3000px photo to the 300px it occupies on the page is invisible and saves megabytes). If all you have is the scan, a 200KB target keeps it presentable — and recruiters' parsing software handles real text far better than scanned text anyway, which is one more reason to convert a scanned resume back to editable Word and re-export when the formatting matters.

When one click isn't enough: the split-and-rebuild tricks

Two workflows rescue files that won't hit a tight target directly:

• Split, then compress. Portals that cap uploads at 100KB usually accept multiple files. Split the PDF into logical parts — application, certificates, ID — and compress each part separately. Three 90KB files beat one impossible 100KB target.
• Rebuild a stubborn scan. Export the pages as JPGs, run them through the image compressor at aggressive settings, then reassemble into a PDF. You control quality per page, and the result is often 30–40% smaller than what in-place compression can manage on messy scanner output.
• Re-scan if you own the paper. 150 DPI grayscale beats 300 DPI colour at a quarter of the size, and for text documents the legibility difference is negligible. The best compression is the data you never capture.
• Never stack two lossy passes. Running the output through a second compressor compounds artefacts without meaningfully shrinking the file — always compress once, from the original, at the target you actually need.

The portals that demand these sizes

Size caps show up wherever forms were built years ago and never revisited. Government application portals and exam boards sit at the strict end (often 100–300KB per document); bank, insurance and KYC document uploads commonly accept 100–500KB; scholarship and university systems frequently cap supporting documents at 200–500KB each; and HR systems impose per-attachment limits anywhere from 200KB to a few megabytes. The pattern is always the same — a scanned certificate or ID that a phone scanner saved at 2MB, and a form that wants a fraction of that. Check your portal's exact number and pick the matching preset; when it allows 200 or 500KB, take it and keep the extra sharpness.

Scans of IDs and tax forms — keep them off other people's servers

Think about what people compress to these sizes: Aadhaar and passport scans, tax forms, medical records, signed contracts. Uploading those to a random compression service means trusting an unknown server, an unknown retention policy, and an unknown jurisdiction with your identity documents. This compressor runs in your browser — the file is parsed, compressed and rebuilt on your own device, and the page keeps working with Wi-Fi switched off. For the deep mechanics of PDF size (DPI, colour spaces, JBIG2, why 'export as PDF' beats 'print to PDF'), the complete PDF compression guide goes further.