Where PDF File Size Actually Comes From (Hint: It's Rarely the Text)

Take a 40-page report full of dense paragraphs, headings, and a table or two, and export it to PDF with no images at all. The result is often under 200 KB — sometimes closer to 100. Now add six photographs, one per section, at whatever resolution a modern phone camera produces by default. That same document can jump to 30 or 40 MB. The text didn't get heavier. The photos did all the work, and understanding why explains almost everything about how PDF compression tools actually operate.

Text and vectors are already about as small as they get

A page of body text in a PDF isn't stored as a picture of letters — it's a sequence of drawing operators referencing font glyph outlines: "draw glyph 47 at this position, glyph 12 next to it," and so on, plus a reference to the font object that defines what those glyph shapes look like. A typical page of text might take a few kilobytes of content-stream instructions. Fonts add more, but a well-built PDF embeds only a subset of a font — just the glyphs actually used in the document, not the full character set — which keeps even embedded font data to tens of kilobytes rather than megabytes. Vector graphics (a logo drawn as paths, a chart rendered as lines and fills) are similarly lightweight: a few dozen path-drawing instructions describe shapes that would take a much larger raster image to represent at the same visual quality. There's very little slack to squeeze out of any of this — text and vector content is already close to information-theoretically minimal for what it represents.

Images are a completely different story

A photo embedded in a PDF is raw or lightly-compressed pixel data, and pixel data is heavy by nature. An uncompressed 12-megapixel photo is roughly 36 MB before any compression at all (12 million pixels × 3 bytes per pixel for RGB). Even after JPEG compression — which most camera-sourced photos already have applied once — that same photo commonly still lands somewhere between 3 and 8 MB depending on the camera's default quality setting, because phone cameras are generally tuned to preserve quality rather than minimize file size, on the reasonable assumption that storage is cheap and the photo might get cropped or edited later. Embed six or eight such photos into a document and you've accounted for the entire size jump described above — the text and layout are rounding errors next to that.

What compression actually does, mechanically

Compressing a PDF is, in the overwhelming majority of cases, really "find every embedded image object, decompress it, recompress it more aggressively, and swap the smaller version back in." That recompression can happen a few ways: increasing JPEG compression (accepting more visible quality loss for a smaller file), downsampling resolution before recompressing (a 300 DPI scan doesn't need to stay at 300 DPI if the document will only ever be viewed on a screen, so resampling it down to 150 DPI first, then compressing, cuts pixel count and file size together), or in the case of images that were embedded as lossless PNG when they didn't need to be (a photo, not a screenshot with sharp edges and flat colors), re-encoding as JPEG entirely, which can cut size dramatically since PNG's lossless approach is a poor fit for photographic content with continuous gradients.

Every one of these is a genuine quality tradeoff, not a free win — this is different from, say, zipping a text file, where compression is fully reversible and lossless. Recompressing an already-JPEG image at a lower quality setting throws away information permanently; downsampling resolution throws away pixels permanently. A compression tool worth using lets you pick how aggressive that tradeoff should be, because "as small as possible" and "as small as possible while a printed page still looks sharp" are genuinely different targets depending on what the document is for.

Why a text-only PDF barely shrinks, no matter what you do

This is the direct consequence of everything above: run a compression pass on a PDF that's pure text and vector graphics, and you'll typically see single-digit percentage size reduction at best — mostly from tightening up stream compression (PDF content streams are usually already Flate/zlib-compressed, so there's a ceiling to how much smaller that gets) and stripping unnecessary metadata or unused embedded resources. There's no large image payload to recompress, so there's nothing for the dominant size-reduction technique to act on. If a "compress PDF" tool claims to shrink a text-only document by 80%, that's worth being skeptical of — either it's silently rasterizing the whole document to low-quality images (destroying text selectability and searchability in the process, a bad trade almost nobody wants) or the original file had unusual bloat, like an oversized embedded color profile or leftover editing history, that isn't representative of typical text-heavy PDFs.

Practical implication

The useful mental model, once you know where the bytes actually live: check what's driving a large PDF's size before reaching for a compressor. If it's six high-resolution photos, a compression pass on those images will do most of the work and there's real room to save megabytes. If it's ninety pages of pure text, the file was probably already small, and no compression tool is going to conjure savings that aren't there to find. ThePDF compression tool on this site works by targeting embedded images specifically — recompressing and, where appropriate, downsampling them — rather than applying some generic shrink operation to the whole file, because that's where essentially all of the recoverable size actually is.