What If a PDF Cannot Reach 100KB?

The measured 135 KB best-effort case

Our July sample was not a scan. It was a synthetic, 240-page PDF built with dense, uncompressed text content streams so we could isolate structural compression. The input measured 3.84 MB (4,023,756 B). At 100KB, the live service returned 135 KB (138,689 B) and identified it as the best effort rather than pretending it had met the cap. The 200KB, 500KB, 1MB and 2MB runs also returned 135 KB. Once the streams had been encoded efficiently, the document had reached its practical floor in this compression path. Repeating the 100KB request could not cross the target without changing what the PDF contained.

Why some larger files do reach 100KB

Starting size does not tell you whether a file is capable of reaching 100KB. In June, an 11.06 MB photo-heavy report reached 96 KB and a 7.16 MB colour scan reached 76 KB. In July, a 5.22 MB (5,469,469 B) scanned-style sample reached 93 KB (94,894 B). Those files carried raster images, so the compressor could reduce resolution and image detail until they fitted. The 3.84 MB dense-text file was smaller at the start but had fewer disposable bytes. Its words, page boundaries and drawing instructions were the document. The useful question is therefore not “How large is it now?” but “What can be removed or represented more efficiently without losing required content?”

A target is a request, not a guarantee

The 100KB selection tells the service which ceiling you need. It cannot make every valid PDF cross that line safely. When the tool reports a best effort above the target, read both numbers before downloading and do not rename the outcome as success. The file may still be useful if the portal has a slightly larger allowance or a support team can grant an exception. If the limit is firm, the best-effort result is a diagnostic checkpoint: generic compression has taken the available saving, so the next attempt must change the source, the page set or the receiving requirement. Running the same unchanged input again is not a new strategy.

Dense text and vectors have a structural floor

Images can lose pixels gradually. Text characters, vector paths, form fields and page instructions do not behave that way. They can be encoded, deduplicated and organised efficiently, but after that, further reduction risks deleting information or breaking the document. A long statement full of selectable text, a technical drawing made from thousands of vector lines, or a form with many repeated objects may therefore stop above a severe target even though it contains no photographs. Embedded fonts also occupy a minimum amount of space when the recipient needs those characters rendered correctly. This is why “text compresses well” and “this text PDF cannot reach 100KB” can both be true: good structural compression still has a finite endpoint.

Page count turns a small total into a tight budget

A fixed 100KB allowance has to hold the entire document: its catalogue, fonts, page descriptions and every piece of required content. The July case had 240 pages. Even though each page was light compared with a scan, their accumulated instructions created a floor. Removing blank, duplicate or genuinely optional pages can help because it removes content rather than asking the encoder to represent the same content more cheaply. Do not delete pages merely to satisfy a number if the recipient requires them. Check whether the portal allows several uploads, whether it expects one combined document, and whether separating pages would make the submission harder to understand before you split anything.

For born-digital files, go back to the source

If the PDF came from Word, a design package, a reporting system or another source application, make a new export rather than printing and rescanning it. Remove unused pages and oversized images in that source. Use its standard small-file or web export where available, and make sure fonts are subset rather than repeatedly embedded. A clean export may remove the inefficient streams that created the problem while keeping genuine text selectable. Printing the document to another PDF can sometimes flatten awkward structures, but it can also remove links, form fields, accessibility information or selectable text. Keep the original and verify the new copy page by page before relying on that route.

For scans, change the scan rather than crushing the output

A scan gives you different levers. If you still have the paper, rescan at a lower but readable DPI, use greyscale when colour carries no evidence, crop empty borders and capture each page squarely. These changes reduce the pixels entering the PDF, which is more controlled than repeatedly degrading an already compressed copy. The July scanned-style sample shows why this can work: it moved from 5.22 MB (5,469,469 B) to 93 KB (94,894 B) at the 100KB target. That does not guarantee every scan will remain legible. Stamps, signatures, photographs and small serial numbers need a close check, and colour must stay when it conveys required information.

Split the document only when the receiving process permits it

Splitting can turn one impossible bundle into several acceptable files because each upload receives its own allowance. It is appropriate when the portal provides several slots or the recipient explicitly accepts parts. Give the files clear names and preserve page order so nothing is mistaken for a separate document. It is not appropriate when the form asks for one continuous statement, one signed agreement or a single chronological record. In that case, ask before dividing it. A technically successful upload that separates signatures from their terms or drops context is not a successful submission.

Know when to challenge the 100KB requirement

A 100KB cap may be a hard system rule, but it may also be guidance written for short scans rather than a long evidential bundle. If the required pages cannot fit while remaining complete and readable, contact the receiving organisation. State the measured best effort plainly: the original size, the 135 KB result, and the steps already tried. Ask whether a larger file, several files, an email attachment or another upload route is acceptable. Do not imply that the compressor is broken when it has exposed a structural floor, and do not submit an unreadable file merely because it is 100KB. The recipient needs usable evidence, not just a compliant byte count.

A careful order of operations

Confirm the portal's real limit and whether it uses one file or several. Run one compression attempt from the best available original. If the result is above 100KB, identify whether the pages are scans, photographs, normal text or dense/vector content. Improve the source accordingly, then make one fresh PDF and test it. Split only with permission. If the complete, readable document still stops above the cap, preserve that result and ask the recipient for an accepted alternative. This order avoids the common trap of repeatedly compressing a deteriorating copy while never addressing the material that sets the floor.

How we measured

We built the dense-text sample specifically to isolate content-stream behaviour, POSTed it to every target on the live service, and recorded the returned byte sizes without substituting a local result.

• Measured and documented by PDF Size Reducer on 20 July 2026 using the live tool.

Common questions