Skip to content
MyPDFilesLocal PDF tools

Developer Tools

PDF Size Analyzer

A byte-level breakdown of where your PDF weight actually is.

Processed locally in your browser. Your file is not uploaded to any server. How this works

  1. 01Add your file
  2. 02PDF Size Analyzer
  3. 03Download

Runs in your browser · nothing uploaded

About PDF size analyzer

Compressing a PDF without looking at it first is guesswork, and it is usually guesswork in the wrong direction. Someone with a forty-megabyte file assumes it is "too many pages" when in fact two photographs account for thirty-four megabytes and the remaining several hundred pages of text cost almost nothing. Someone else strips metadata to save space and recovers four kilobytes. This tool attributes the bytes: how much sits in image streams, how much in embedded font programs, how much in page content streams, how much in metadata and how much in the structural overhead of objects and the cross-reference index. With that breakdown the right action is usually obvious and often surgical — downsample two images, or accept that a file made of embedded fonts and text is already about as small as it can honestly get.

How to PDF size analyzer

  1. 01

    Load the PDF

    Every object is measured by its stored length, then attributed to a category.

  2. 02

    Read the breakdown

    Categories are shown with byte totals and percentages of file size, largest first.

  3. 03

    Drill into the largest category

    If images dominate, the per-object list names the offenders. If fonts dominate, the count of embedded faces is the lever.

  4. 04

    Then compress deliberately

    Go to the compressor knowing which setting will matter, rather than trying presets until one looks acceptable.

What this tool does

  • Byte totals and percentages for images, embedded fonts, content streams, metadata, annotations and structural overhead
  • Per-image byte weight, so the handful of objects that usually explain everything sort to the top
  • Embedded font weight per face, with subset fonts distinguished from full faces
  • Content stream weight, which is the floor for a text-heavy document
  • Metadata and XMP weight, reported honestly — usually kilobytes, occasionally megabytes when a producer embeds a preview or an unusual payload
  • Structural overhead: object dictionaries, the cross-reference index and any unreferenced leftovers from earlier edits
  • A plain-language conclusion naming the dominant category and the realistic saving available

Limitations worth knowing

Every PDF tool has constraints. Stating them plainly is more useful than discovering them halfway through your work.

  • Attribution uses stored stream lengths, so category totals sum to slightly less than the file size. The remainder is the xref index, trailer and inter-object whitespace.
  • This analyses; it does not compress. Nothing here modifies your file.
  • A file dominated by content streams and embedded fonts has little left to give. The honest answer in that case is that it is already small.
  • Bytes left behind by incremental updates are reported as unreferenced overhead, but only where they can be identified from the object graph.
  • Encrypted files must be decrypted first, since stream lengths cannot be attributed to categories without reading the objects.

How your file is handled

This tool runs entirely inside this browser tab. When you choose a file, your browser reads it from your own disk and hands the bytes to JavaScript running on this page — no network request carries your document anywhere. You can confirm that yourself: open your browser’s developer tools, switch to the Network panel, and run the tool. You will see no upload.

Nothing is stored after the fact. Closing or reloading this tab discards the file, the result and everything derived from them, because none of it ever left your machine. Read how local processing works.

Questions about PDF size analyzer

Why is my PDF so much larger than the document seems to justify?

In the overwhelming majority of cases, images stored at far higher resolution than they are displayed at. A photograph placed small on a page keeps every pixel it arrived with. This breakdown tells you in one look whether that is your situation, and the image inspector will tell you the effective DPI of the offenders.

Will removing metadata make a meaningful difference?

Almost never to file size — metadata is typically a few kilobytes. Removing it is a privacy measure, not a compression measure, and this report shows you the actual number so you do not have to take that on faith.

What if fonts are the largest category?

That happens in documents using many faces, or CJK fonts where even a subset is substantial. The options are genuinely limited: use fewer faces, or ensure the producer subsets rather than embedding full faces. Not embedding is the one thing not to do, because that trades file size for text that renders differently elsewhere.

What is structural overhead and can I get rid of it?

It is the cost of the file being a file: object dictionaries, the cross-reference index, and anything left behind by previous edits. A clean rewrite with compressed xref and object streams reclaims some of it, which is part of what a compressor does. For most documents it is a small share, but in a file with tens of thousands of tiny objects it becomes visible.

How much smaller can this file realistically get?

Read the dominant category. If images hold most of the bytes and their effective DPI is well above the output target, large reductions are available with no visible change. If content streams and embedded fonts hold most of the bytes, expect single-digit percentages, and treat any tool promising more than that as either re-rasterising your text or discarding your fonts.

Tools that pair with this one

Read more about this

Background