Why your book PDF is 80 MB, and how to shrink it

A book PDF that arrives at 80 MB is not a book with too much in it. It is a book carrying data nobody will ever look at: a cover photograph at camera resolution, screenshots exported at retina scale, and four weights of a typeface where the text used two. The reader sees none of that. Their email client, their download, and — if you are selling on Kindle — your royalty statement all do.

What is actually in the file

Before compressing anything, it is worth knowing what you are compressing. A typical 200-page book breaks down roughly like this.

Text is nothing. If your file is enormous, an image is responsible — and if it is not an image, it is fonts. There is no third possibility worth chasing.

The resolution arithmetic

Print needs 300 pixels per inch at the size the image is placed. That last clause is the one people skip. Resolution is not a property of the file — it is the ratio between the pixels you have and the inches they are stretched across.

A phone photograph is around 4,000 pixels wide. Dropped into a 5-inch column it is carrying roughly sixteen times the data that the page can print, and file size scales with area — so cutting the width in half quarters the bytes. That is where the 80 MB goes.

The rule is one line of mental arithmetic: placed width in inches × 300 = the pixel width you need. A full-bleed image on a 6 × 9 in page needs about 1,900 pixels across. Anything beyond that is storage, not sharpness.

JPEG for photographs, PNG for everything else

Choosing the wrong format is the second-biggest cause of a bloated file, and it goes wrong in both directions.

A photograph saved as PNG is typically five to ten times larger than the same photograph as a quality-85 JPEG, and no reader can tell them apart. A screenshot saved as JPEG is smaller than the PNG and looks visibly worse — fuzzy halos around every letter. Both mistakes are common because the export dialog remembered the last thing you did.

Quality 80 to 85 is the honest range for JPEG. Above 90 you are storing compression artefacts in high fidelity; below 70 the sky in a cover photograph starts to band. If you are working from Markdown, this is decided when you save the image, not later — see images in Markdown that stay sharp in the PDF for how the placement side of it works.

Fonts: subset, and use fewer of them

Every typeface you use is embedded in the PDF, because that is what makes the file portable. What matters is whether it is embedded whole or subset.

• A subset font contains only the glyphs the book actually uses — usually 150 to 300 of them. Typically 100 to 400 KB per weight.
• A full font contains the entire character set, which for a modern family means Cyrillic, Greek, and a few thousand glyphs you will never type. Two to four megabytes per weight.
• Four weights of two families is eight embedded fonts. Subset, that is under 3 MB. Embedded whole, it is 20 MB before you have added a single image.

Most export pipelines subset by default; some CAD and design exports do not. The other half of the fix is editorial rather than technical: a book that uses regular, italic, bold and one display weight looks more considered than one using seven, and it weighs a quarter as much. Choosing fonts for a book is largely an argument for using fewer.

The delivery fee nobody reads about until later

For a PDF you sell yourself, file size is a courtesy. On Kindle it is money. Amazon's 70% royalty option subtracts a delivery cost calculated per megabyte of the delivered file — around $0.15 per MB in the US at the time of writing, and worth checking against current KDP terms before you plan around it.

An illustrated book that nobody bothered to downsample can hand most of its royalty back to the store, one sale at a time. This is the single most expensive formatting mistake in self-publishing, and it is invisible until you read the statement. The rest of what a Kindle file has to satisfy is in what Amazon KDP actually wants from your file.

Compressing a PDF you have already made

Fixing the source images is always better, because it is the only approach that does not degrade anything. But when the source is gone or the deadline is not, Ghostscript will re-encode every image in an existing PDF:

# 300 ppi, suitable for print
gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.7 \
   -dPDFSETTINGS=/prepress \
   -dNOPAUSE -dQUIET -dBATCH \
   -sOutputFile=book-print.pdf book.pdf

# 150 ppi, suitable for screen reading and email
gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.7 \
   -dPDFSETTINGS=/ebook \
   -dNOPAUSE -dQUIET -dBATCH \
   -sOutputFile=book-screen.pdf book.pdf

Two warnings, both learned the hard way. /ebook downsamples to 150 ppi, which is fine on a screen and soft on paper — never send that file to a printer. And Ghostscript re-encodes images that were already compressed, so running it twice compounds the loss. Compress once, from the best original you have.

Preview on macOS has a Reduce File Size filter that does something similar and much more aggressively; it is fine for emailing a draft to a proofreader and unfit for anything a printer will see.

What size a book should actually be

Keep two exports of any illustrated book: a print interior at 300 ppi for the printer, and a screen edition at 150 ppi for the version buyers download. They are the same book, and the second one is usually a fifth of the size. What each one has to satisfy before it goes out is covered in what makes a PDF print-ready.

1. Find the biggest image. Sort the source folder by size; the top three files are usually most of the problem.
2. Work out the placed width in inches and multiply by 300. Resize to that, not to whatever the camera produced.
3. Re-save photographs as JPEG at quality 82 and screenshots as PNG.
4. Check the fonts are subset, and cut any weight the book does not genuinely use.
5. Export twice — print at 300 ppi, screen at 150 — and check the screen one on a phone before you sell it.