Guide · 7 min read
How to Reduce a PDF Under an Upload Limit
Shrink an oversized PDF to fit a form cap: which mode to try first, how target sizes work, and what to do if it still fails.
Last updated: 2026-10-03
Tools for this guide
Read the limit the way the form states it
Every upload form describes its cap differently, so start by reading the exact wording next to the upload button: the maximum size, the accepted formats, and whether the limit covers each file or the entire submission. Many portals set a cap, and the figure changes from form to form, so check the requirement on the form itself rather than assuming last year's number still applies. Write the number down and subtract a safety margin of at least ten percent, because portals often measure decoded size or add processing overhead that pushes borderline files over.
While you are there, confirm the surrounding rules: whether multiple files are allowed, whether pages can be split across uploads, and whether scanned signatures or photos are actually required. A form that accepts three separate 10 MB files needs no heroic compression of a 25 MB bundle — splitting is the entire solution. Knowing the real constraint before you compress decides whether you need mild savings, a target-size run, or structural surgery on the document.
Try the three modes in the right order
The Compress PDF tool offers three modes behind a single selector, and the order you try them determines how much quality you preserve. Start with Lossless: it re-saves the document with object streams, costs zero quality, and helps files that carry removable overhead. When it cannot help, it says so plainly — the note explains the file has no removable overhead and suggests Smart mode — so you lose nothing by trying it on files of unknown origin.
Next comes Smart, the default and the workhorse: it recompresses embedded raster images in a Web Worker while text and vectors pass through untouched, so layout stays identical and text stays selectable. Reserve Maximum for last, because it rasterizes pages at stepped resolution and quality levels and rebuilds the PDF from those images — the smallest output, but text becomes non-selectable, which the result note states directly. Measured Smart runs complete in 0.3 to 2.1 s even on a 50 MB input, so walking the ladder from gentle to strong costs seconds and preserves quality whenever the gentler mode suffices.
Set a target size instead of guessing
Once you know the cap, type it into the target size field rather than compressing and hoping: choose the 100KB, 200KB, 500KB, or 1MB preset chips, or enter a custom value just under the form's stated limit. The target drives both Smart and Maximum modes — the interface notes that Lossless re-saving cannot aim at a size — and the engine walks its compression ladder until a pass lands under the goal. That automation replaces the old trial-and-error loop of compress, check, repeat with a single declared intent.
Set the target slightly below the real cap to leave headroom for the portal's own handling. If the engine reaches your goal, the result note confirms it; if even the strongest honest pass lands above it, the note reports the closest achievable size instead of silently destroying readability to hit the number. That honest floor is a feature: a tool that claims to fit any file under any cap is either lying about the size or about the quality, and this one does neither.
Predict your outcome from the file type
Measured Smart-mode results, reproduced end to end in headless Chromium against the production build, let you forecast how your file will behave before you run it. Scanned documents saved 58.6%, photo-heavy pages saved 77.8%, mixed text-and-image pages saved 71.4%, and a single large photo page saved 96.7% — all with text extraction identical before and after on every fixture containing text. If your PDF is scans or photos, expect substantial savings in about one to two seconds; the 50 MB fixture finished in 2.1 s with sequential page processing and canvases released between pages.
The same measurements explain the disappointing cases honestly. Text-only pages saved 0% and came back byte-identical in 0.3 s, as did an already-compressed tiny file — there were simply no embedded images to recompress, and the tool reported an under-5% notice rather than pretending. So diagnose first: zoom to 400% and check whether page content is fuzzy scans or crisp text, or simply run Smart mode once and read the note. Image weight means compression will solve your problem; text weight means you need fewer pages, not stronger settings.
When the file still does not fit
If Smart mode with a target still lands above the cap, stop compressing the same bytes harder and change the document instead. The Split PDF tool divides a document into page ranges — say pages 1 to 5 and 6 to 10 — while Extract PDF Pages pulls specific pages or ranges like 2, 5 to 8, and 12 into one new file. Both operations rearrange original content without re-rendering it, so the extracted pages keep their full quality; you are removing weight by removing pages, not by degrading the pages you keep.
Common patterns that work: extract only the pages the form requires and leave appendices out; split a large submission into two parts where the form accepts multiple uploads; compress the extracted subset once from its original rather than re-compressing an already-compressed file. If none of that suffices, Maximum mode remains the last resort with its stated selectability tradeoff. And if the file is password-protected or damaged, no mode can proceed — remove the password by re-saving without one, or regenerate the file from the original application, as the error messages direct.
Verify size, text, and layout after every run
Each compression run ends with exact before-and-after sizes, so compare the output against your margin-adjusted target before doing anything else. Then verify content two ways: visually, by spot-checking two or three pages at 150 to 200% zoom for crisp body text and legible fine print; and structurally, by selecting a paragraph and confirming it highlights and copies. Smart mode preserves text operators through save and load round-trips — unit tests assert exactly that — and production measurements show word counts unchanged, but a ten-second check on your own file replaces trust with evidence.
Keep the workflow lossless in the organizational sense too: never overwrite your only original with a compressed copy, and never re-compress an output when a gentler source is available. Files up to 150 MB are accepted and processed locally in your browser, so re-running from the original is cheap and private. Archive the original, submit the verified compressed copy, and if a recipient later needs full quality, the pristine source is one upload away.
Respect the input ceiling on very large files
The Compress PDF tool accepts files up to 150 MB and processes them entirely on your device, which sets two practical boundaries worth understanding before you start. The first is the cap itself: a file above 150 MB is refused at selection time, and no mode or target can change that, so oversized originals must be reduced in the application that created them — export in parts, lower the scan resolution at the source, or divide the document before bringing it here. The second boundary is memory and patience on your own hardware: because decoding happens in your tab rather than on a server, a 50 MB photo-heavy file converts locally without uploading a byte, and measured runs finished that fixture in 2.1 s with pages processed one after another and canvases released between pages. Smaller scans and mixed files finished in 0.3 to 1.5 s, with scanned pages saving 58.6%, photo-heavy pages 77.8%, and mixed pages 71.4%.
Turn those facts into a routine for heavy files. Close competing tabs before compressing anything above a few dozen megabytes, so the browser has room to decode without pressure. Run one mode at a time from the original — Lossless first for the free savings, then Smart with your target — and read the result note after each run instead of stacking passes. If the document is long, consider splitting it into ranges first and compressing each part separately; smaller inputs process faster, and a part that turns out to be text-only will report its honest 0% with an under-5% notice in 0.3 s rather than consuming a long Maximum-mode render for nothing. Keep every original until the compressed parts are verified, because re-running from sources is cheap while reconstructing a deleted original is impossible.
Run the rejection checklist when the portal still says no
A rejection after successful compression usually means the file violates a rule other than size, so work through the checklist in order. Confirm the compressed size against the cap with at least ten percent margin, because portals often measure decoded bytes or add their own processing overhead that pushes borderline files over. Confirm the extension is exactly .pdf and the filename uses plain characters — spaces are usually tolerated but unusual symbols, very long names, and double extensions cause failures on strict forms. Confirm the file opens without a password prompt, since encrypted files are refused with a message asking you to remove the password first by re-saving without one; compression cannot unlock anything and never attempts to. Finally, confirm the page count matches what you intended, because an extraction that silently dropped pages will fail a human reviewer even where it passes the uploader.
If every item checks out and the upload still fails, change the delivery instead of the file. Re-download the compressed copy fresh — interrupted downloads truncate bytes and read as damaged files — and retry the upload in a current browser with extensions disabled, since aggressive blockers occasionally interfere with form scripts. Where the form permits multiple attachments, split the document into ranges and upload parts; where it does not, extract only the pages the instructions require and submit that leaner file. As a last step before contacting support, test the file locally once more: open it, zoom two or three pages to 150%, select and copy a paragraph, and confirm the copy pastes cleanly. A file that passes those checks is structurally sound, which tells support the problem sits with the form — and that evidence shortens the exchange considerably.
Accept the honest floor on text-native files
Some PDFs cannot be compressed further by any honest method, and recognizing them early saves the entire session. Text-native documents — exported reports, generated invoices, word-processor output — store characters, fonts, and vector drawing commands rather than pictures, so there are no embedded images for Smart mode to recompress. Measured runs prove the point bluntly: a five-page text-only fixture came back byte-identical at 0% saved in 0.3 s, with word extraction unchanged at 3,420 to 3,420, and an already-compressed tiny file behaved identically. The tool reports these cases with an under-5% notice instead of fabricating savings, and Lossless mode adds its own plain message when a file carries no removable overhead. Treat those notices as diagnoses, not errors — they tell you the file was already efficient.
The remedy for a file at its honest floor is structural, never stronger settings. Remove what the recipient does not need: delete filler pages, extract only the required ranges, or drop full-page photographs that add weight without meaning. When the weight lives in one or two scanned pages inside an otherwise text document, split those pages out and compress them separately rather than forcing the whole file through Maximum mode and flattening text that was never the problem. If the document must stay whole, rebuild from the source application — export with web-oriented settings, downsample pasted screenshots before exporting, and regenerate — because bytes removed at creation time never need compressing afterward. Smaller page counts and leaner sources succeed where compression dials cannot.
Compare Smart and Maximum side by side before committing
When both modes seem plausible, run the comparison deliberately instead of guessing which one the form wants. Start from the untouched original and compress once in Smart mode with your target set, recording the output size and the result note; then return to the original and run Maximum mode the same way. Open both outputs and inspect two or three representative pages at 150 to 200% zoom — body copy, fine print, signatures, diagrams — noting where each mode lands on legibility. Then perform the selection test in each file: drag across a paragraph and confirm whether it highlights and pastes. Smart outputs keep selection working with layout identical; Maximum outputs look close at reading zoom but surrender selectability, exactly as the interface warns before you run it.
Choose with the recipient's workflow in mind, not the smaller number alone. Forms that parse, search, or quote document text — applications, legal filings, academic submissions — need Smart output, even when Maximum shaves further kilobytes. Maximum earns its place for scan-only bundles read purely on screen, where no text layer existed to preserve and the smallest file genuinely serves the reader. Either way, submit only the compared winner and archive the original alongside it; keeping both outputs plus the source lets you answer any follow-up request — a print-quality resend, a text extraction, a page reordering — without reconstructing the session. Measured Smart savings of 58.6% on scans, 77.8% on photo pages, 71.4% on mixed content, and 96.7% on a large photo page, each in 0.3 to 2.1 s, mean the comparison itself costs almost no time.
Decide when splitting beats compressing
Compression and splitting solve different problems, and choosing wrong wastes sessions. Compress when the document's contents are all required but its encoding is wasteful — scanned pages, photo-heavy reports, phone-camera captures — because Smart mode removes precisely that waste while text and layout pass through untouched. Split when the contents themselves exceed the need: appendices nobody requested, duplicate scans, draft chapters, or a full manual where the form asks for one section. The diagnostic question is simple: if every page must reach the recipient, compress; if some pages need never travel, remove them first and compress what remains. Long submissions frequently need both in sequence — extract the required pages, then aim the leaner file at the cap — and that order matters, since compressing before trimming spends quality on pages destined for deletion.
Read the form's structure before deciding, because its upload design often answers the question for you. Multiple attachment slots invite splitting directly: required pages through the portal, supporting material as separate named files, each compressed against its own slot's cap. A single upload box with a hard cap pushes toward one compressed bundle, possibly with appendices summarized instead of attached. A form that names specific pages — schedules, certificates, identification — wants extraction of exactly those pages rather than a squeezed whole. When none of these patterns fit and the honest floor still sits above the cap, contact the form's administrator with the numbers in hand: original size, compressed size, page count, and the cap itself. Administrators grant exceptions and alternative channels far more readily to senders who arrive with measured facts than to those who merely report that uploading failed.
Keep a compression log for repeated submissions
Anyone who files the same documents through many portals — monthly reports, recurring applications, compliance filings — should stop relearning the settings every time and write them down instead. A simple log records, per destination, the portal's stated cap, the mode and target used, the resulting size, and any quirks discovered: which slot accepted multiple files, which validator rejected long filenames, which form measured decoded bytes above the nominal cap. The next submission to that portal then starts from a proven recipe instead of a fresh experiment, and Smart mode's speed — measured runs finished in 0.3 to 2.1 s — means even a from-scratch pass costs little. What the log really saves is the diagnosis time around failures, because the quirks column remembers what frustration forgets.
Fold the log into the archiving habit from the earlier sections. Store each portal's submitted copy beside its log entry with matching names, so a resend request months later needs no regeneration and no guesswork about which variant cleared that portal's validator. Note the tool's behavior changes too, if any ever affect your numbers — a new mode, a changed preset — with the date, so old entries stay interpretable. Over a year of filings, this record becomes its own kind of leverage: patterns emerge showing which portals tighten caps without notice, which document types compress reliably, and where splitting has consistently outperformed squeezing. Decisions backed by a year's own measurements outclass advice remembered from a guide, including this one.
Frequently asked questions
Why does the tool say my file cannot shrink further?
Text-only and already-efficient files contain no shrinkable image data, so the tool returns them unchanged with an under-5% notice instead of faking savings — measured text-only fixtures come back byte-identical at 0%. When you see that notice, the path forward is removing pages or images, not stronger compression.
Should I use Maximum mode right away for the smallest file?
No. Maximum mode rebuilds every page as an image, so text stops being selectable or searchable, and the interface states that tradeoff. Start with Smart mode, which keeps text intact; measured Smart runs finished in 0.3 to 2.1 s, so testing it first costs almost no time.
Can I compress a password-protected PDF?
No. Encrypted files are refused with a clear message asking you to remove the password first by re-saving the file without one, then trying again. The same applies to damaged files, which get a message suggesting you re-save from the original application.
The compressed file is still over the limit. Now what?
Split the document into ranges or extract only the pages the form requires, then compress the lighter part again from its original. Sending the required pages as a clean smaller file is more reliable than forcing the full document through repeated compression passes.
How long should compression take?
Measured Smart-mode runs finished in 0.3 to 2.1 s on a desktop, including a 50 MB photo page in 2.1 s. Your time depends on the file and the device, since everything processes locally in your tab — scans and photo pages take longer than text, and older hardware takes longer than newer. Progress is narrated during the run, so a large file that looks busy is working, not stuck.
Try it now — free, no signup
Smaller PDFs for email limits and faster sharing. Files stay on your device.
Open Compress PDF