Compress PDF to 100 KB without uploading: a measured local test

Written by Feroz Sheikh · Founder, Doha, Qatar

Updated 2026-09-30. This is a working note for a live tool, not legal, tax, or professional advice.

A 100 KB limit is a strict file acceptance condition, not a promise that every document can become small and readable. OpenToolSuite tries a compact PDF copy first and uses rendered page images only when that copy remains too large. The processing happens in the current browser. You still choose whether to upload the finished document to a separate application portal. This guide records a synthetic test and explains what to check before sharing your own result.

Start with the exact instructions shown beside the destination upload field. A field labelled 100 KB might be checked against 100,000 bytes or 102,400 bytes. This tool uses 1 KB = 1,024 bytes, so its 100 KB setting is a 102,400 byte cap. When the portal specifies a different number, enter a smaller custom cap and inspect the actual downloaded byte size. A rounded size label alone cannot establish whether a portal will accept it.

Choose the PDF size cap tool, select a PDF already available on your device, and set the cap to 100. The tool accepts up to three PDFs, each no larger than 25 MB. The page rendering path supports up to 20 pages. A larger page count may still pass through the compact path if it is already small enough; when rendering is needed, split the source before trying again. Keep the original in a separate folder.

The first attempt saves the PDF using object streams. This can help documents with inefficient structure while retaining their text objects. It does not necessarily reduce large embedded images. The result label says text kept when this path succeeds. The measured selectable-text fixture demonstrates this case. Do not generalize that label into a guarantee about signatures, complex forms, accessibility tags or every interactive feature. Review any document that depends on those features in its usual reader.

If the compact copy exceeds the cap, the tool renders each page and places a JPEG image of that page into a new PDF. It tries several page scales and JPEG quality settings. This is a different type of result: words remain visible as pixels, but selectable text, links and form fields do not survive. For a simple scan that may be acceptable. For a signed agreement, a fillable form or a document that needs accessible text, it may be unsuitable.

Our four-page scan fixture contains fictional table rows, decimal amounts, an eight-point small-print line and numbered pages. It was generated as image-only PDF pages and compressed losslessly before this test. It is therefore a useful controlled challenge, not a sample of actual applicant documents. The evidence table below gives input and output byte counts from the real tool UI. The downloadable report retains SHA-256 identifiers and the browser environment so the measurements can be checked.

Review the result before uploading. Open all four pages rather than judging the first thumbnail. Read the smallest line, inspect decimal points and similar characters such as 0 and O, and confirm that page edges are not missing. A file can satisfy a byte cap while failing the human requirement to read a certificate or reference number. We do not assign an OCR accuracy score or claim portal acceptance from this synthetic fixture.

For an identity document, check which sides and pages the recipient actually requests. Removing required content to reach a size limit is not a valid compression strategy. If your source has unrelated pages, extract only the requested pages before applying the cap. If it has oversized blank margins, create a better scan from the original document. Avoid repeatedly compressing a previous JPEG-based result, because each lossy pass may further damage fine print.

The privacy observation has a specific scope. During these compression runs, the benchmark watched page network requests for bodies carrying data and recorded the result in the public report. Compression was run online because the renderer assets needed to load. This is evidence about the observed preview and selected workflow, not proof that a web page makes no requests of any kind. Opening a site, loading code and optional measurement are separate from uploading the selected file.

You can repeat the experiment with harmless files before selecting a private document. Generate the public fixtures, run the production preview and use the included benchmark script. For a manual check, open developer tools before the operation, inspect the Network panel and look for requests caused by selecting or processing the file. Treat an unexplained request carrying document bytes as a reason to stop. Do not paste private file contents into a console or a support message.

If the tool cannot reach the cap, it should report that outcome rather than label an oversized PDF as ready. Try a shorter requested page set, a cleaner scan or a cap explicitly allowed by the recipient. An encrypted PDF needs to be opened in an appropriate trusted reader first. Very complex or damaged PDFs may fail browser processing. The original should remain available until the destination accepts the checked copy and you have confirmed that it displays correctly.

Use the 100 KB result only when both conditions are satisfied: the actual byte count fits the recipient's limit, and the important content remains usable. The synthetic measurements answer whether this controlled file reached the tool's cap. They do not answer whether your institution accepts flattened pages or whether your source will produce the same size. That decision comes from the recipient's current instructions and a careful review of your own output.

Reference: Chrome DevTools: inspect network activity

Reference: Manual checks and reproduction commands

Reference: Deterministic fixture generator

Reference: Local output verification recipe

Reference: Synthetic scan input

Reference: Measured 100 KB output

Reference: Measured compact text output

Open the PDF size cap tool

All guides