Compress a PDF to 100 KB: what fits, measured
Rishabh Pandey
An upload form says "PDF, maximum 100 KB" and your file is 2 MB. Most advice says "use a compressor" and stops there. We wanted to know what actually fits in 100 KB, so we ran the same three PDFs through Ghostscript at every common resolution and wrote down the sizes. Then we checked why one kind of PDF refuses to get smaller no matter what you do to its images.
The short version: 100 KB holds about two full pages of photos at 72 dpi, or one at 100 dpi. A text document can usually fit, but only if the tool shrinks the embedded fonts as well as the images. Most tools don't.
First, what "100 KB" means
Before you squeeze anything, check which kilobyte the form counts. In the SI system a kilo is exactly 1,000, so 100 KB is 100,000 bytes. The binary prefix "kibi" (KiB) is 1,024 bytes, which makes 100 KiB 102,400 bytes (NIST, prefixes for binary multiples). Plenty of software still writes "KB" and means 1,024.
That 2.4% gap matters at the edge. A file of 101,000 bytes is "98.6 KB" to software that divides by 1,024, and it still fails a form that counts in thousands. File managers also round the number they show, and upload portals almost never say which kilobyte they use. The safe target is under 100,000 bytes. Check the exact byte count in your file's properties, not the rounded number.
What we measured
We used three test files from the benchmark set we built for our PDF tools. Every one is public domain or generated by us:
- Photos, 8 pages: each Letter page is a full-bleed NASA photo scanned at 300 dpi (9.1 MB).
- Scan, 2 pages: a deliberately poor office scan of printed text, image only, no text layer (220 KB).
- Report, 10 pages: a normal document exported from a browser, with headings, a table, a chart, two photos and real selectable text (661 KB).
We downsampled every image to a fixed resolution with Ghostscript 10.06 (pdfwrite, JPEG quality 60, color and grayscale) and recorded the output. Ghostscript's own presets use the same knobs: /screen sets images to 72 dpi and /ebook to 150 dpi (Ghostscript docs, high level devices).
| Image resolution | Photos, KB per page | Photos, 8 pages | Scan, 2 pages | Report, 10 pages |
|---|---|---|---|---|
| 150 dpi | 155 | 1,245 KB | 307 KB | 199 KB |
| 100 dpi | 79 | 633 KB | 167 KB | 172 KB |
| 72 dpi | 45 | 361 KB | 88 KB | 162 KB |
| 50 dpi | 24 | 195 KB | 44 KB | 155 KB |
| 36 dpi | 14 | 113 KB | 22 KB | 152 KB |
Measured 29 October 2026, Ghostscript 10.06.0, color output. 1 KB = 1,024 bytes in this table.
Three things stand out.
Photo pages shrink with the square of the resolution, a little less in practice. Halving the dpi cuts the pixels by four, and the bytes fell by a bit more than three: 155 KB a page at 150 dpi, 45 KB at 72 dpi, 14 KB at 36 dpi. So measure one page at the resolution you want rather than scaling from another. Then you can budget before you start. Divide 100 KB by the per-page cost at the lowest resolution you'd accept:
- at 100 dpi (still sharp on screen), about 1 page fits;
- at 72 dpi (fine on screen, soft in print), about 2 pages;
- at 50 dpi, about 4 pages, and small print in a photographed document stops being readable here;
- 8 photo pages don't fit even at 36 dpi (113 KB in our table), and at that resolution the page is already a blur.
The image below shows the same crop at the original quality, at 72 dpi and at 36 dpi.

The scan behaves like the photos. A scanned page is just a picture of text. At 72 dpi our 2-page scan came out at 88 KB and the text was still readable on screen. At 50 dpi it was 44 KB, but letters like "e" and "c" started to merge. For a scan, 72 dpi is the floor we'd use for anything an official will read.
The report would not go below 150 KB. Lowering the image resolution from 150 dpi to 36 dpi saved only 47 KB, then nothing more. At 36 dpi the two photos inside it weighed about 5 KB together. The other 145 KB or so was not images at all.
Why a text PDF gets stuck
We opened the stuck report to see where the bytes were. It embeds eight font subsets: Arial regular and bold three times each, Arial italic and Georgia. That's normal for a PDF printed from a web browser. Each subset only holds the characters the document uses, so the usual tip ("subset your fonts") is already done.
What's left inside each font is hinting. TrueType fonts carry small programs that nudge each letter's outline to fit the pixel grid at small sizes on low-resolution screens. Microsoft's typography team describes hinting as essential for text that has to stay legible "at small sizes on low resolution output devices", and notes that outlines at higher resolutions stay unchanged (Microsoft Learn, TrueType hinting). PDF viewers draw text from the outlines and smooth it, and the copy you print or zoom into doesn't use the hints. We measured how much of the report's font data is hinting: 156 KB of the 192 KB of font data (before compression), or 81%, spread across all eight fonts (64–88% each).
Removing the hinting tables (and the per-letter instructions) leaves every letter's shape, every character code and the text layer untouched, so the text stays selectable and searchable. Ghostscript's presets don't do this. Its options cover embedding and subsetting, not stripping hints (Ghostscript docs). qpdf, the other common free tool, can pack objects into compressed object streams and re-encode images, but it doesn't edit fonts or downsample images (qpdf manual, command-line options).
This is the step that made our own Compress PDF to 100 KB tool different. On the same 10-page report it reached 97 KB with every word still extractable. Ghostscript, lowering the image resolution step by step, couldn't get under 150 KB. On the 8-page photo file it reached 90 KB, where Ghostscript's best attempt at the target was 100 KB with visibly worse pages. We measured both on 23 October 2026 against the original pages using SSIM, a standard score of how similar two images look, where 1 means identical (Wang, Bovik, Sheikh and Simoncelli, the SSIM index).
| File, target 100 KB | Our tool | Ghostscript, best setting |
|---|---|---|
| Report, 10 pages | 97 KB, SSIM 0.997, all text kept | can't go below 150 KB |
| Photos, 8 pages | 90 KB, SSIM 0.761 | 100 KB, SSIM 0.676 |
An SSIM of 0.76 is not a good-looking photo. It means that 8 photo pages at 100 KB will be soft whatever tool you use. The numbers above show why: the page budget simply isn't there.
Grayscale saved less than we expected
"Convert to black and white" is the second most common tip. On our files it barely helped, and on the photos the grayscale output was slightly larger (380 KB against 361 KB at 72 dpi). Our photo pages were mostly gray moon dust to begin with, so there was little color to remove. On a colorful document grayscale will save more. Still, the measured result is a reminder that resolution is the setting that moves the size. Color is a second-order knob. Try Grayscale PDF after you've picked the resolution, not instead.
A decision list for a 100 KB limit
- Count the pages the form actually needs. A mark sheet, an ID or a certificate is usually one page. If your PDF has a blank back side or a cover sheet, remove those pages first with Organize PDF. Every photo page you drop frees 45 KB at 72 dpi.
- Know what kind of PDF you have. Try to select a word in it. If you can, it's a text PDF, and the fonts are the problem, not the pictures. If you can't, it's a scan or a photo, and resolution is everything.
- For a scan or a photo of a document, aim for 72 dpi. One or two pages fit. If there are more pages, ask yourself whether the form wants them all.
- For a text PDF, use a tool that keeps the text as text. Rasterizing a text page (turning it into a picture) is the worst option. It makes the file bigger at readable quality, and the words can no longer be searched or copied. We learned this the hard way: an earlier version of our own tool rasterized text pages under a tight target, and on the 10-page report it produced 546 KB, missed the target and lost all the text. That's why it now shrinks images and fonts first.
- Check the result at 100% zoom before you upload. Read the smallest print on the page: dates, registration numbers, signatures. If you can't read it, neither can the person checking your application.
- Check the byte count, not the rounded size. Aim for under 100,000 bytes (see the first section).
If the limit is per file and your document has many pages, no setting will save you. Split it into the pieces the form asks for with Split PDF, and compress each piece.
What about photos of documents?
If you're starting from phone photos rather than a PDF, resize the photo before you make the PDF. A 12-megapixel phone photo (4,000 × 3,000 pixels) that fills an A4 page works out to about 340 dpi along the long side, roughly five times the pixels of a 150 dpi page. Our Compress Image to 100 KB tool does that for a single image. For several pages, Compress PDF to a specific size takes the photos straight in and combines them. Both run in your browser, so the document doesn't leave your computer.
What we'd tell a form designer
If you run an upload form, 100 KB per PDF is tighter than it looks. Our measurements say it fits one readable photo page, or a few text pages if the tool is careful. Say whether you count KB in 1,000 or 1,024 bytes. Say which pages you need. And if the documents are scans that officials will read, 150–200 KB per page is a more honest limit: that's what a full page cost at 150 dpi in our table.
For a larger budget, the general Compress PDF tool keeps 110 dpi images and the text untouched, which is the right default when nobody has set a hard cap.
Sources
- NIST: Prefixes for binary multiples (kilo = 1,000, kibi = 1,024).
- Ghostscript documentation: High level devices (pdfwrite), distiller parameters and the PDFSETTINGS presets.
- qpdf manual: Running qpdf, command-line options (object streams,
--optimize-images). - Microsoft Learn: TrueType hinting.
- Zhou Wang, Alan Bovik, Hamid Sheikh, Eero Simoncelli: The SSIM index for image quality assessment (IEEE Transactions on Image Processing, 2004).
- Our measurements: Ghostscript 10.06.0 resolution sweep on 29 October 2026, and our tool benchmark of 23 October 2026, on a public-domain test corpus (NASA photos, the US Constitution text).
Building a software product?
Talk it through with us on a free 30-minute call, or email [email protected]. You can also try our free tools.
Suggested Articles
Here are a few more articles you might like.


