Why Your PDF Is 40 MB, and Which of the Four Causes You Actually Have

A PDF is not a document in the way a Word file is a document. It is a container that can hold text drawn from embedded fonts, vector artwork, photographs, scanned page images, form fields, attachments and several superseded copies of all of the above. Two files of the same length in pages can differ in size by orders of magnitude, because they are made of different things.

So the useful question is not “how do I compress this PDF” but “what is taking up the space”. Once you know that, the right action is usually obvious, and it is sometimes to rebuild the file rather than compress it.

“Compress PDF” describes a goal, not an operation

When you compress a JPEG there is one lever: how much image detail you are willing to discard. A PDF has no equivalent. Depending on what the file contains, shrinking it might mean re-encoding photographs at a lower resolution, removing font programs embedded twice, discarding years of tracked edits, flattening form fields, or converting the page content to a different representation altogether.

Those are unrelated operations with unrelated trade-offs, and a tool that does one of them will do almost nothing to a file whose bulk comes from another. That is the usual reason people conclude that PDF compression does not work: it worked exactly as designed, on a file it was never going to help.

Cause 1: scanned pages, which are photographs of documents

A scanned PDF contains no text at all. Each page is a single raster image, stored in the file with an image compression filter and drawn to fill the page. The words you see are pixels.

Size here is governed by the same things that govern any image: pixel dimensions and encoding. Scanners often default to settings that are generous for archiving and excessive for something you are emailing. The conventional numbers people work with are 300 pixels per inch for print reproduction and somewhere around 72 to 150 for reading on screen. Those are conventions rather than rules, but a 600 dpi colour scan of a text memo holds roughly sixteen times the pixel count of a 150 dpi version of the same page.

The encoding matters as much as the resolution. PDF supports several image filters for different content: according to iText’s knowledge base entry on PDF filters (retrieved 31 July 2026), DCTDecode is used for JPEG images, JBIG2Decode for JBIG2, CCITTFaxDecode for CCITT and JPXDecode for JPEG 2000, while page content streams normally use FlateDecode. The bilevel filters exist because black text on white paper compresses extraordinarily well at one bit per pixel and badly as a colour photograph. Scans are the cause where compression has the most room to work, because the content is already raster data and re-encoding it destroys nothing structural.

Cause 2: oversized images inside an otherwise normal document

The second case is a real text document that happens to carry photographs, screenshots or charts placed at their original resolution. A phone photo dropped into a report keeps its full pixel dimensions even though it is displayed a few centimetres wide, and the file stores every one of those pixels.

The tell is a document whose page count is modest and whose text is perfectly selectable, yet which is far larger than its neighbours, with a handful of pages accounting for nearly all of it. This is the friendliest cause to fix, because downsampling those images to something reasonable for their display size leaves the text untouched. Reducing them before they go into the PDF is better still: our image compressor and resizer exist for that step.

Cause 3: embedded fonts, and why subsetting matters

For a PDF to render identically everywhere, the font programs it uses are normally embedded in the file. A full family with several weights, hinting and a large character set is a substantial amount of data, and a document using six typefaces embeds six font programs.

The standard mitigation is subsetting: embedding only the glyphs the document actually uses. The PDF specification gives subset fonts a recognisable name. Section 9.6.4 of ISO 32000-1 requires the font’s PostScript name to begin with a tag of exactly six uppercase letters followed by a plus sign, so a subset of a font called Poetica appears in the file under a name like EOODIA+Poetica. If you open a document’s properties in a PDF reader and look at its font list, entries with that six-letter prefix are subsets; entries without it are likely full embedded fonts.

Fonts rarely make a document enormous on their own. They matter in two situations: short documents, where a few full font programs dominate a file with almost no other content, and merged documents, where the same font ends up embedded several times because each source file carried its own copy. Different subsets of one font within a single file must carry different tags, which is what lets a reader keep them apart and also what makes them awkward to collapse into one.

Cause 4: accumulated revisions, forms and leftovers

PDF allows a file to be modified without rewriting it. Foxit’s developer documentation on incremental updates (retrieved 31 July 2026) quotes the PDF 1.7 specification on the point: “The contents of a PDF file can be updated incrementally without rewriting the entire file. Changes are appended to the end of the file, leaving its original contents intact.”

That design is why digital signatures work: a signature covers the bytes that existed when it was applied, and later changes are appended after it rather than written over it. The side effect is that a file edited many times can carry objects it no longer displays. A photograph you deleted on page four may still be in the file; the reader simply no longer points at it.

The same category covers form fields and their appearance streams, annotation and comment history, embedded attachments, colour profiles, and metadata blocks that several producers have each added a copy of. None of it is visible when you read the document, and none of it responds to image compression.

Working out which one you have

You can usually identify the cause in under a minute with nothing but a PDF reader.

1. Try to select a line of body text. If you cannot select it, and a search for a word you can plainly see returns nothing, the page is an image. That is cause 1. If a search does find text on a scanned-looking page, the file has been through OCR, which adds an invisible text layer over the image but leaves the image in place.
2. Page through and watch for the slow pages. Pages that take a visible moment to appear, or stay blurry for a beat while scrolling, are the ones carrying large images. Weight concentrated in a few pages is cause 2; weight spread evenly across every page points at scans or fonts.
3. Zoom to 400% on a heading. Text drawn from embedded fonts stays sharp at any zoom. Text that breaks into soft pixel blocks is part of an image.
4. Open the document properties and read the font list. Count the embedded fonts and note how many lack the six-letter subset prefix. On a short document with a long font list, that is cause 3.
5. Re-save the file through a different route. Exporting, printing to PDF or using a “save as” that writes a fresh file rather than appending will typically drop superseded objects. If a plain re-save with no other change makes the file noticeably smaller, you were carrying cause 4.

If you are comfortable in a terminal, a rough count of the %%EOF markers in the file hints at how many times it has been incrementally updated, since each appended revision ends with its own trailer. Treat it as a hint rather than a measurement: the same byte sequence can appear inside embedded content.

What actually helps, by cause

What our own PDF compressor does, precisely

Our compress PDF tool takes one specific approach, which suits some of the causes above and is wrong for others. Here is what it actually does.

It renders every page of your document to a canvas in the browser using PDF.js, at 1.5 times the page’s natural size. The default PDF unit is 1/72 inch, which Datalogics’ knowledge base article on PDF page size limits (retrieved 31 July 2026) describes as “a default unit size of a point, or 1/72 of an inch”, so that render works out at roughly 108 pixels per inch of page. Each rendered page is then encoded as a JPEG at the quality you choose with the slider, and a new PDF is assembled with one full-page JPEG per page.

So the honest description is: it does not optimise your PDF, it replaces it with pictures of itself. The consequences follow directly from that.

• The output has no text. Nothing in it can be selected, searched, copied or read by a screen reader, and any OCR layer is gone.
• Links, bookmarks, form fields, annotations, comments and attachments are not carried into the new file.
• Vector artwork such as logos, line drawings and charts becomes pixels, and will not stay sharp when zoomed or printed at a large size.
• The rebuilt pages take the pixel dimensions of the render, so the output page geometry is 1.5 times the original in PDF units. It looks the same on screen; it is not a faithful replacement if exact page dimensions matter to you.
• A file that needs a password to open cannot be rendered, because the tool never asks you for one, so it will not process such a file.

Against that, the trade it makes is a real one for the cause it suits. A scanned document, or one dominated by large photographs, is already raster content, so re-rendering at about 108 pixels per inch and re-encoding as JPEG usually removes a great deal of data that was doing no work on screen. On a file that is mostly text set in subset fonts, or mostly vector graphics, the same process can easily produce a larger file than you started with, because compact instructions have been replaced with photographs of their output.

We cannot give you a percentage. The result depends entirely on what your document is made of, and any single number quoted for “typical” PDF compression is describing one document rather than yours. The tool shows the before and after sizes when it finishes; if the result is not smaller, or not smaller enough to justify losing the text, discard it and keep your original.

Everything happens in your browser: the file is read into memory in the page and never sent anywhere. The one external network request involved is for the PDF.js worker script, loaded from a CDN, which is program code arriving rather than your document leaving. Because every page is rendered individually, a long document takes a while.

If you need the text to survive, this is not the tool for the job, and we would rather say so than have you find out afterwards. A desktop PDF editor or a server-side optimiser that downsamples the embedded images while leaving the text and font objects intact is the better approach in that case.

When the answer is to rebuild rather than compress

Compression is a repair applied to a file that was built badly. If you still have the source, whether that is a Word document, an InDesign file or a LaTeX project, regenerating the PDF with the images downsampled and the fonts subset on export beats any post-hoc processing and keeps the text as text.

Rebuilding is also right when only part of the document is needed. Extracting the six pages someone actually asked for with split PDF is a larger reduction than any compression pass, and it costs nothing in quality. The same logic applies in reverse: if you are assembling a file from photographs, resize and compress the images first and then build the document with image to PDF, rather than building a heavy file and squeezing it afterwards.

For a scan, the cheapest fix is upstream. Scanning a text document in greyscale at a moderate resolution produces a file that needs no compression at all and stays readable.