Compress a PDF to 100 KB and keep the text
Upload limits are written as a number — 100 KB, 200, 500 — and the usual way to hit them is to turn every page into a picture. That works, and it costs you the words. This tool re-encodes the pictures inside your PDF until the file fits, and copies the text through, so it is still selectable when you land under the limit.
How can I compress a PDF to 100 KB without uploading it? Set the target on the form below and the tool searches for the largest picture quality that still fits the budget, on your own device, in your own browser. No upload, no account, no size ceiling on the file you bring. A PDF that is too big for an email attachment, a visa portal or a submission form is the ordinary case here — the limit you are fighting is usually a file size limit at the far end — an email attachment field, a visa portal, a submission form — and it is measured in kilobytes, which is why the tool prints the figure both ways.
- Nothing is uploaded
- Text stays selectable
- Works offline
- Unlimited & free
On a phone? This runs there too — grab the QR code and share links →
Drop your PDF here
or paste from the clipboard
PDF — one file at a time, no size limit, nothing leaves your device
The size you need to land under
Applied when you run itWhat the file actually contains
What we measured, and what it means
Three documents were printed to PDF by the same browser and then asked to hit a target — the same thing you would do by hand, only without the upload. The tool walks quality from high to low and stops at the first setting that fits, so the numbers below are the largest quality that still made the budget, not a quality somebody picked.
The file you get back also depends on which JPEG encoder the browser has already loaded. This site's encoder prefers a WASM module whenever that module has downloaded, and a module is a download, so a first visit and a later one are not the same run. Both runs are measured here, and the result panel names the encoder that answered. The figures below are the first run, which is what a new visitor gets.
- Two pages, one photo, body text around it — 299,733 bytes asked for 100 KB: 89,559 bytes. Inside the 102,400-byte limit. One image was re-encoded, at quality 30, and its pixel dimensions were not touched at all.
- The same two-page file asked for 200 KB: 174,091 bytes, and for 500 KB: 283,032 bytes. Both inside budget, at quality 75 and 90 respectively — the bigger the budget, the sharper the pictures stay.
- Four photos, four pages — 1,689,943 bytes asked for 100 KB: 70,401 bytes. Here quality alone was not enough, so the search moved down its ladder and settled at an 800-pixel maximum edge, re-encoding all four pictures.
- The same four photos asked for 500 KB: 491,351 bytes. Same quality, and this time no pixel was resized — a comfortable budget is reached with re-encoding alone.
- Text only, no pictures at all — 11,381 bytes at every target from 100 KB to 500 KB. There are no image streams to take bytes from, so the original is handed back untouched instead of being rewritten for nothing. The same is true whichever encoder is live.
- First run or second run, the numbers move a little, and neither codec wins every time. On the two-page document under 100 KB the first run lands at 89,559 bytes and the run with the module at 100,684; on the four photos under 200 KB the first run lands at 197,939 and the module at 144,763. But at 500 KB on the four photos the first run is the smaller file, 491,351 against 423,414, and on the two-page document at 500 KB it is the other way round, 283,032 against 381,077. So the tool says which encoder it used instead of quoting one figure as if every visitor would see it.
The same limit, by the other route
There are two ways to get under a limit like this, and they are not the same trade. One re-encodes what is inside the file; the other throws the file away and keeps a picture of it. To keep this honest, we reproduced the second route here on the same fixtures — render each page, encode it as a JPEG, rebuild a PDF that has no text in it at all — and then asked a separate PDF reader to read the words back. It is our own reproduction of the technique, not a measurement of any vendor's build.
| Same fixture, same 100 KB limit | Re-encode the images inside | Draw every page as a picture |
|---|---|---|
| Two pages, one photo, 3,001 characters of text | 89,559 bytes — all 3,001 characters still readable | 84,252 bytes — none of them readable |
| One page, no photos, 746 characters of text | 11,381 bytes — all 746 characters still readable, and the original file handed back | 79,348 bytes — none of them readable |
The picture route did, in both cases, come in under 100 KB — that is not the point of contention. It is that the budget was reached by spending the text. Search compress pdf to 100kb and the tools that answer all take the same route; several of them say so in their own copy: textify.tools writes that text becomes non-selectable in the compressed output. We have not tested their builds, so we quote them and we measure our own.
The method, the fixtures and the per-image figures are kept with the rest of the project's measurements: three A4 documents generated by the browser's own print-to-PDF, run through this site's own encoder, with every target-size result read back by a second, independent PDF parser.
How it works
Whether you want to compress a PDF to 100 KB, to 200, or to 500, the job is the same: the bytes are in the pictures, and the words were compressed a long time ago. So the size search goes after the pictures and leaves everything else alone.
- The file is read on your device. There is no upload step, so the whole job happens locally — nothing to wait for, nothing to leak.
- The document is walked and the images inside are counted. Plain JPEG image objects are picked out; ones with an alpha channel, one-bit masks and anything the browser's decoder refuses are counted and left alone.
- The search starts at the highest quality and walks down. Each try re-encodes the images and measures the document. The first quality that lands inside the target is the answer, which means you get the sharpest picture the budget can afford rather than the first one that happened to fit.
- Only when quality runs out does it downscale. It walks a ladder of maximum edges — 1600, 1200, 1000, 800, 640, 480 pixels — and takes the widest rung that can still reach the limit, so the pictures stay as large as they can be.
- The file is written back out. Image streams are swapped in, the byte count in each dictionary is corrected, and the cross-reference table is rebuilt from the offsets actually written — a stream that changed length moves every object after it.
If the target turns out to be unreachable, the tool tells you the smallest file it could produce rather than handing you something over the limit. If the document is encrypted, or its objects are packed into compressed object streams, it reports that and gives the original back.
Frequently asked questions
How do I compress a PDF to 100 KB?
Set 100 as the target and hand the file to the tool on this page — it runs in your browser, so the document never travels anywhere. The tool then looks for the largest picture quality that still lands inside 100 KB: it tries the highest quality first, measures, and walks quality down until the whole document fits. Only when quality cannot reach the budget does it start shrinking the pictures themselves, and even then it uses the widest pictures that still fit. On our two-page test document — one photograph and body text around it, 299,733 bytes — it landed at 89,559 bytes, inside the 102,400-byte limit, with only one image re-encoded and its pixel dimensions untouched. Had the browser already loaded the WASM codec, the same request would land at 100,684 bytes instead: still inside the limit, and the search would simply have stopped at a higher picture quality. The same request also turns up online spelled without a space, as “compress a PDF to 100kb”; the tool reads the number, not the spacing.
Will my text still be selectable at 100 KB?
Yes, and that is the whole reason this page exists. Most tools that answer “compress PDF to 100 KB” do it by drawing every page on a canvas and rebuilding the document out of pictures; that gets you under the limit and the words stop existing as text. This tool touches only the image streams inside the file. The content stream that draws the words, the fonts and the page tree are copied across, so the text stays text. We checked with a second, separate PDF reader rather than with our own code: a two-page document that started with 3,001 readable characters came back at 89,559 bytes with all 3,001 of them still readable, and still selectable.
Can I compress to 200 KB or 500 KB instead?
Yes — the same tool, and the same search. If you arrived here wanting to compress a PDF to 200 kb, or to compress a PDF to 500 kb, that is the same tool with a different number in the box: 100 is the default only because it is the figure most portals and attachment fields name. On the four-photo test document we measured 197,939 bytes against a 200 KB limit and 491,351 bytes against a 500 KB limit, and in both cases the picture dimensions stayed where they were; with the WASM codec loaded the same two budgets came out at 144,763 and 423,414. The larger the budget, the higher the quality the search can afford and the fewer pixels it has to throw away.
My PDF has no photos in it. Can it still be made 100 KB?
Probably not, and the tool says so rather than pretending. A document that is nothing but text — a contract, an invoice, a report — has already compressed its words once and carries no image streams to take bytes from, so there is nothing to re-encode. Our text-only test file is exactly that case: 11,381 bytes, inside a 100 KB limit already, and it comes back at 11,381 bytes with the original bytes intact. The same thing happens if the images in a file are unusually awkward: ones with an alpha channel attached, one-bit masks, or anything the browser's decoder refuses. The result line counts those.
Is my PDF uploaded to a server?
No. The file is read with the browser's own file reader and every step — reading the structure, decoding each embedded image, trying qualities, rebuilding the offsets — happens on your machine. There is no server-side component that accepts a PDF at all. The page loads its compression engine from this site's own assets, and the target-size search runs on top of that engine in the same tab.
Does it shrink my pictures, or only re-encode them?
It re-encodes first and only shrinks when it has to. Shifting pixels is the destructive part: a picture resized to fit a budget is a picture that can never go back to the size it was. So the search starts at the highest quality and walks down; if the budget is reached that way, every image keeps the pixel size it had. Only for documents where quality alone is not enough does it move down a ladder of maximum edge widths — 1600, 1200, 1000, 800, 640, 480 pixels — and take the widest rung that can still reach the limit. On the four-photo test document a 100 KB budget needed 800 pixels; on the same four photos under a 500 KB budget the search finished without touching a single pixel dimension.
Why do you measure 100 KB as 102,400 bytes?
Because that is the arithmetic: 100 times 1024. Some tools treat a kilobyte as 1000 bytes and quietly hand you back something a little larger than the limit you asked for, which in practice is the same thing as failing the check on the far end. This tool compares against 100 × 1024 = 102,400 bytes and reports the result in both figures, so you can see the margin you actually have.
Does it work on encrypted or password-protected PDFs?
No, and it refuses rather than guessing. A document that carries an encryption dictionary does not have readable offsets, so any edit risks producing a file that will not open; those are handed back exactly as they came in. The same is true of a file whose objects are packed into compressed object streams — the tool reports how many it found rather than pretending it saw inside them. Password protected documents are refused rather than guessed at.