Getting a PDF under 1 MB without making it unreadable

The short answer

One megabyte is an arbitrary number someone else chose — an upload form, a mail server, a submission portal. Whether you can hit it depends almost entirely on one thing: how much of the file is photographs.

If the file is a text document with some pictures in it, 1 MB is usually comfortable and you will lose nothing visible at normal reading size. If it is a long scan, every page is a photograph and the arithmetic may simply not work. That difference is worth thirty seconds of checking, because it decides whether you are tuning a setting or solving a different problem. The order below is deliberate: cheapest loss first, and stop as soon as you fit.

The practical sequence

1. Find out what is making the file big

Do this before you touch a setting. Run the file through /pdf-page-count, which reports the page count, the page sizes and whether there is a text layer. Then divide: a 6 MB file over 40 pages is about 150 KB a page, which is a text document with illustrations. A 6 MB file over 4 pages is roughly 1.5 MB a page, which is a scan or close to one.

The text layer is the other half of the answer. If there is none, the document is images all the way down and every byte you remove comes out of image quality. If there is one, the text costs almost nothing and the images are the whole target.

2. Recompress the images

/compress-pdf-to-1mb is built for exactly this. It walks progressively stronger settings and stops at the first one that fits under the target, so you end up with the least damaged version that meets the limit rather than the smallest one it could produce. That is the whole point of using it rather than reaching straight for the strongest setting.

What happens underneath is described in full in how PDF compression works: each embedded image is decoded, downsampled according to how large it is actually drawn on the page, and re-encoded as JPEG. Page content streams are not touched, so text stays selectable and searchable, vectors stay sharp, and links, form fields and annotations survive. Everything runs in your browser; the file is not uploaded.

3. Escalate only if you have to

The stronger settings soften detailed images — noticeably so on scanned text, which tolerates JPEG quality reduction worse than photographs do. Take that trade only after confirming the document is still legible for its actual purpose. If even the strongest setting does not reach 1 MB, the file is telling you something, and the next section is about what. For other limits, the same mechanism is available at /compress-pdf-to-2mb and /compress-pdf-to-500kb.

When 1 MB is not achievable

For some documents the target is simply out of reach at any quality you would be willing to send. It is better to know this in the first minute than after four attempts.

Do the arithmetic. One megabyte is 1,024 kilobytes. Divide that by the number of pages that carry a full-page image:

• 60-page scan. That is roughly 60 full-page photographs. 1,024 ÷ 60 is about 17 KB per page. A full page of scanned text compressed into 17 KB is visibly degraded — soft, blocky around the letterforms, and awkward to read for any length of time.
• 12-page scan. About 85 KB per page. Tight, but a legible screen-resolution scan can live in that budget.
• 3-page scan. About 340 KB per page. Comfortable.

The point is not the exact numbers, which depend on what is on the page — a dense photograph costs far more than a sparse form. The point is that the per-page budget is the thing that determines feasibility, and you can compute it in five seconds for your own file. If it lands in the low tens of kilobytes per full-page image, no setting will save you, and no tool that claims otherwise is telling the truth about what it is doing to your document.

A document that is mostly text behaves completely differently, because the text costs almost nothing. Forty pages of prose with no images is already well under 1 MB before you start, and compressing it further wins only single-digit percentages — the text is stored as a Flate-compressed content stream and has already been squeezed. There is nothing there to recover. More detail on that in why some PDFs cannot be compressed.

What to do instead

When the arithmetic says no, stop compressing and change the problem.

• Split the document. Three parts under 1 MB each beat one unreadable file. /split-pdf divides a document into pieces; /extract-pdf-pages pulls out a specific range when the recipient only needs part of it. This is usually the right answer for long scans, and it costs no quality at all.
• Send a link instead of an attachment. Size limits are almost always a property of the transport, not the recipient. Cloud storage, a shared drive or a file-transfer service removes the constraint entirely and delivers the original.
• Send text, not a document. If the layout does not matter — a reference, a quotation, something that will be pasted elsewhere — /pdf-to-text extracts the text layer, which will be a tiny fraction of the size. Note that this only works on a document that has a text layer. iBuildPDF does not do OCR, so a scan will yield nothing.
• Reduce the page size. If the document is on a large format it does not need, /resize-pdf changes the page dimensions, which reduces how large images are drawn and therefore how many pixels they need.
• Ask whether the limit is real. Plenty of stated limits are inherited defaults nobody has revisited. Confirming that the recipient can take 5 MB is faster than degrading a document to 1 MB.

Checking the result is still usable

A file that meets the limit is not the same as a file that does its job. Open the output and check four things before sending it.

1. Does the text still select? Drag across a paragraph. If it highlights, the content streams are intact and the document is still searchable and copyable. If it does not — and it did before — something rasterised the pages, and that is not recoverable.
2. Are the images legible at 100%? Not zoomed in: at the size someone will actually read them. Zooming to 400% and disliking what you see is not a useful test if nobody will ever do that. Zooming to 100% and struggling to read a scanned paragraph is decisive.
3. Does anything important depend on fine detail? Signatures, stamps, small print in a table, a serial number, a barcode, a hairline in an engineering drawing. These are the first things to dissolve and the last things you notice. Check them specifically.
4. Did the colours shift? CMYK images that are recompressed are converted to RGB, which can move colours slightly. Irrelevant for most documents; not irrelevant for anything going to print.

If it passes all four, send it. If it fails on point three, go back a setting and split the file instead — a legible document in two parts is worth more than an illegible one in one.