The form says “upload failed” or “file size not within allowed limit.” No explanation, no indication of how far off you are. Before touching a compression tool, spend thirty seconds confirming the two numbers you’re actually dealing with.

First, check the real numbers side by side

Right-click the PDF, open its properties or “Get Info,” and read the actual file size in KB or MB — not what you remember, not what you assumed when you scanned it. Then check the portal’s instructions page (not the error message, which usually just says “invalid size”) for the stated limit on that specific field. Forms often set different caps for different fields on the same page — a photo capped at 50KB, a signature at 20KB, a certificate PDF at 300KB. Rejected at the photo field doesn’t mean your certificate PDF is the problem.

If your file is 2.4MB against a 300KB cap, you need real compression, not fine-tuning. If it’s 340KB against 300KB, a light pass does it. Check the other direction too: some portals also enforce a minimum, usually to block a blank or corrupted upload. An unusually small file (a scan that came out as a few KB) is a “too small” rejection — the fix is re-scanning properly, not compressing further.

Once you know the cap, don’t aim exactly at it. Target something a bit under — 270KB for a 300KB cap, say — rather than 299KB. Portals round file sizes differently than your OS does, and a file that reads as “under 300KB” on your computer can land a few bytes over by the time it’s uploaded and re-checked server-side. A small margin costs you almost nothing in quality and removes the boundary case entirely.

With both numbers in hand, here’s what’s usually actually wrong.

1. The scan resolution is higher than it needs to be

How to spot it: the PDF is a scanned document — a certificate, a signed form, an ID card — and it’s disproportionately large for its page count. A single-page scan running 3-5MB is a resolution problem, not a content problem.

Why it happens: scanners and scanning apps default to 300 DPI or higher because it’s the “safe” setting for print. A portal reading the document on screen doesn’t need that much — most verification just needs the text and seal legible at normal zoom, which 150-200 DPI handles fine.

Fix: if you control the scan, rescan at a lower DPI before uploading. If you already have the PDF, target-size compression does this after the fact — it downsamples the embedded page images to whatever resolution fits your target, so you don’t have to guess a DPI number.

2. Embedded images are sitting at camera resolution

How to spot it: the PDF isn’t a scan at all — it’s a Word or Google Docs export, or a digitally filled form, that includes a photo (a product shot, a screenshot, your own photo) pasted in at full size. An image shot on a modern phone can be 4000+ pixels wide and several megabytes, even though the PDF only displays it at postcard size on the page.

Fix: the image needs resizing to the dimensions it’s actually displayed at — compression alone around an oversized image doesn’t fix the root problem. Target-size compression handles this the same way it handles scans: it re-renders each page and re-encodes the images to match your target, so a 4000px photo doesn’t silently survive at full resolution inside an otherwise small file.

3. Leftover metadata and unused embedded fonts

How to spot it: the file looks reasonable page-by-page, but the total is still bigger than expected for a mostly-text document. It rarely accounts for the whole overage, but on a file close to the cap it’s often the difference between passing and failing.

Why it happens: PDFs accumulate baggage — editing history, color profiles, full font files embedded for a typeface even if only a few characters used it, thumbnail previews, XMP metadata from whatever tool last touched the file. None of it is visible, all of it counts toward the size the portal checks.

Fix: a compression pass that rebuilds the PDF strips this along with everything else, which is why even a file that “shouldn’t” need much compression often drops noticeably on the first pass.

4. The file is just genuinely over the limit

Sometimes there’s no trick to it — a 12-page document really is 12 pages, and even at reasonable resolution it’s bigger than a 300KB cap allows. This is the most common case by volume, and the simplest to fix: it needs real compression, not cleanup.

Shrink the source before compression even runs

Three things make a compressor’s job easier before you touch a target number, and each one is a five-second pass with its own free tool:

  • Crop dead space. A flatbed scan with an inch of blank scanner bed around the actual page is compressing weight that shows nothing — Crop PDF trims it off first.
  • Drop blank pages. Flatbed and duplex scanners routinely add a blank back page for every printed one-sided sheet, and a “blank” page is still a full-resolution image the compressor has to process. Remove Blank Pages clears them out before compression, not after.
  • Go grayscale if the document doesn’t need color. A black-ink certificate or marksheet scanned in full color is carrying three color channels of data to represent what’s really one channel of information. Grayscale PDF converts it, and the same page compresses noticeably smaller at the same quality afterward.

None of these three replace compression — they just mean the compressor starts from a smaller, cleaner file instead of fighting an oversized one, which usually buys you a meaningfully lower target before quality has to give.

The fix for most of these: exact-target compression

All four causes above point to the same fix. Compress PDF runs entirely in your browser via WebAssembly — nothing uploads anywhere, which matters when the document is an ID, a certificate, or a signed form. Instead of a vague “quality” slider, you type the exact number you need (or use a built-in preset — 200KB for NSP or CUET, 300KB for DU CSAS, 500KB for JOSAA) and it works backward from that target: re-rendering pages, trying a JPEG quality level, checking the resulting size, and stepping quality and resolution down together until it lands at or under your number. If it can’t hit the target, it says so plainly instead of handing you a file that still fails.

Worth knowing before you run it: hitting an exact size means every page gets rasterized into an image and rebuilt as a new PDF, which is true for a scanned document and a typed one alike. Selectable text, a hyperlink, a fillable form field, a digital signature object — none of that survives, because none of it is visible ink. The page looks identical and prints the same, but if the form needs the document to stay text-searchable or fillable afterward, compress a copy and keep your original untouched.

If it still won’t hit the target

Text-heavy documents have a real floor. Hitting a tight target means rasterizing each page into a compressed image, and a long, dense document can’t shrink past a certain point without turning blurry enough to fail a human or OCR check. If the portal accepts multiple smaller files instead of one, Split PDF breaks the document into pieces that each clear the cap on their own, no quality loss involved. If the form insists on exactly one file, compression to the edge of legibility is the only path — check the result at actual zoom before submitting it.

One mistake worth avoiding at this point: don’t take a compressed file that’s still slightly too soft and run it through the compressor again. Each pass re-encodes the page as a fresh JPEG on top of whatever was already lost in the last pass, so a second compression of an already-compressed file loses more detail for the same file size, not less. If the first result isn’t good enough, go back to the original scan and try a different target or the pre-compression steps above — never the already-compressed output.