Find out exactly why your PDF is large — images, fonts, metadata, or compression — with a full diagnostic report and optimization score. 100% browser-based, nothing uploaded.
Drop your PDF to analyze its size
Click to browse or drag & drop
Analyzing…
Reading document structure
Couldn't analyze this file
Something went wrong.
TL;DR — Analyze your PDF's size in seconds
Quick Guide
Three steps, no configuration — the report generates automatically the moment your file finishes loading.
Drag and drop a PDF onto the upload zone, or click to browse. The file loads directly into your browser's memory — it is never sent anywhere.
PDFcrest reads the document's internal object structure — images, fonts, content streams, metadata — and attributes size to every page. Most files finish in a few seconds.
Review the size breakdown, optimization score, and page-by-page detail, then jump to Compress PDF, Edit Metadata, or another tool to act on what it finds.
Why PDFcrest
Compressors guess at settings. PDFcrest's analyzer shows you the actual internal structure first, so you know exactly what you're optimizing.
See exactly which pages, images, and fonts are responsible for size — not just a single number for the whole file.
Analysis runs entirely in your browser with pdf.js and pdf-lib. Your PDF is never sent to a server, so there's nothing to intercept, store, or leak.
A documented, transparent scoring model — not a marketing number — built from real image DPI, font embedding, and compression signals in your file.
Built to handle scanned books and 1,000-page engineering drawings without freezing the tab, by yielding back to the browser between batches.
Download the full analysis — stats, scores, and page data — as JSON for your own records, tickets, or archival workflows.
No account, no watermark, no daily cap on how many PDFs you can analyze.
Comparison
Most "PDF size" tools just show the file size Windows already tells you. Here's what an actual diagnostic analyzer adds.
| Feature | PDFcrest | Adobe Acrobat Pro | Smallpdf / iLovePDF | PDF24 |
|---|---|---|---|---|
| Page-by-page size breakdown | Yes | Yes (desktop only) | No | No |
| Image / font contribution chart | Yes | Partial | No | No |
| Optimization score with formula shown | Yes | No | No | No |
| Runs 100% in-browser (no upload) | Yes | No | No | No |
| Free with no daily limit | Yes | Subscription | Capped | Yes |
| Exportable JSON diagnostic report | Yes | No | No | No |
| Requires an account | No | Yes | Often | No |
Who Uses This
Anyone who has ever asked "why is this PDF so huge?" — a diagnostic step before compressing, emailing, or archiving.
Diagnose why scanned contracts and discovery bundles balloon past email attachment limits before sending.
Find which pages in a set of drawings carry oversized raster images so only those pages need re-export.
Audit legacy scanned records for bloated, uncompressed images before long-term digital storage.
Check imaging-heavy patient records for optimization opportunities without ever uploading protected health data.
Understand why a scanned textbook chapter or slide deck export is too large to submit or share.
Check embedded font subsetting and image DPI before sending a print-ready or web PDF downstream.
Triage which PDFs in a shared drive are worth optimizing before a storage-quota cleanup.
Workflow Recipes
Analyzing is rarely the last step — here's how it fits into a real optimization workflow.
See exactly what's inflating the file, then apply targeted compression instead of guessing at a quality slider.
When the report flags a large XMP or Info payload, remove it directly instead of guessing what's in it.
If the page map shows near-empty or repeated pages carrying real byte weight, remove them before touching images.
Confirm a document is image-only (no text layer), then make it searchable before archiving.
User Feedback
"Finally something that tells me *which* pages are the problem instead of just re-compressing everything and hoping."
— Architecture project coordinator
"Ran it on a 400-page scanned archive and it flagged the exact 12 pages scanned at the wrong DPI. Saved a lot of guesswork."
— Records management lead
"Being able to see it never leaves the browser matters a lot when the PDFs are client contracts."
— Paralegal
Related Searches
The Complete Guide
A PDF size analyzer is a diagnostic tool that looks past the single number your operating system shows for a file's size and examines the document's internal structure — the images, fonts, page content, metadata, and other objects a PDF is actually built from — to determine which of those components is responsible for how large the file is. Where a compressor simply re-encodes everything and hopes for a smaller result, an analyzer answers a more useful question first: why is this file 40 MB, and which of those megabytes can realistically be recovered? PDFcrest's PDF Size Analyzer does this entirely inside your browser, reading the file's cross-reference table and every indirect object it points to, without ever uploading the document anywhere.
A PDF is a container format, and its size is the sum of everything embedded inside it. The most common contributors are high-resolution scanned images (a single page scanned at 600 DPI in color can easily exceed 10 MB on its own), uncompressed or poorly compressed images, embedded fonts that include glyphs never used in the document, duplicated resources that a producer failed to deduplicate, complex vector graphics with thousands of path operations, transparency layers and soft masks that force more expensive rendering data, file attachments, verbose XMP or custom metadata, digital signature byte ranges, and interactive form field data. Most real-world "why is this PDF huge" cases trace back to one or two of these — usually images — rather than an even spread across all of them, which is exactly why a page-by-page, component-by-component breakdown is more useful than a single compression pass.
PDFcrest's analyzer follows a six-stage pipeline entirely in JavaScript, using the open-source pdf-lib and pdf.js libraries: (1) parse the file's low-level object graph via pdf-lib's enumerateIndirectObjects(), which walks every indirect object in the file exactly as stored, without inflating or re-encoding any of it; (2) inspect each object's dictionary to classify it — image, font, annotation, form XObject, pattern, extended graphics state, or anonymous content stream; (3) enumerate every page and its inherited resource dictionary, mapping which images, fonts, and graphics states each page actually references; (4) attribute each object's real, on-disk (already-compressed) byte size to the pages that use it — content streams belong fully to their one page, while resources shared across multiple pages are split proportionally; (5) sum those contributions into per-page and whole-document totals for images, fonts, page content, metadata, and other structural objects; and (6) run those totals through a documented scoring model (see "Under the Hood" below) to produce a Complexity Score, an Optimization Score, and a realistic savings estimate.
Images are stored as XObjects with a Width, Height, bit depth, and a compression filter (DCTDecode for JPEG, CCITTFaxDecode for scanned black-and-white fax-style images, FlateDecode for lossless raw pixels, or JBIG2Decode for bitonal scans) — the filter and resolution together largely determine an image's byte footprint. Fonts can be embedded in full or "subset" (trimmed to only the glyphs the document actually uses, indicated by a six-letter prefix like ABCDEF+Arial); a fully embedded, unsubset font can add hundreds of kilobytes for glyphs that are never rendered. Vector graphics and text live inside page content streams as sequences of drawing operators; dense technical drawings with thousands of path segments produce much larger content streams than a simple text page. Metadata includes the classic Info dictionary (title, author, keywords) and an optional XMP stream, which some editing tools bloat with revision history. Annotations, form fields, and layers (Optional Content Groups) each add their own dictionary overhead and, in the case of form fields with appearance streams, can duplicate rendering data. Transparency — soft masks and non-opaque graphics states — increases rendering complexity and frequently correlates with larger, higher-bit-depth image data underneath it.
For any document produced by scanning paper or exporting a photo-heavy layout, images are almost always the largest contributor, and the reason is arithmetic: an uncompressed 8.5×11" page scanned at 300 DPI in 24-bit color contains roughly 24 million pixels at 3 bytes each — over 70 MB before any compression is applied. JPEG (DCTDecode) compression typically brings that down by 90–98%, but scans saved at unnecessarily high DPI (1200 DPI is common from default scanner presets, four times the pixel count of 300 DPI for the same physical page), in an uncompressed or lightly-compressed format, or as full-color when the source is really black-and-white text, all leave enormous, easily recoverable size on the table.
When the analyzer's report points to images, the standard fixes are: scan text documents at 200–300 DPI rather than 600–1200 DPI, use JPEG compression for photographs and CCITT/JBIG2 for pure black-and-white scans rather than PNG-style lossless encoding, and recompress rather than re-scan when possible. When it points to fonts, subsetting embedded fonts to only the glyphs used typically recovers the largest share with zero visual change. When metadata is flagged, stripping unused XMP and Info fields is free size with no quality tradeoff. When it points to page content, flattening unnecessary transparency groups and removing duplicate or blank pages before compressing anything else avoids wasting compression effort on pages that shouldn't exist in the first place.
Under the Hood
This is the real formula implemented in this page's own JavaScript — an analytical scoring model for diagnostics, not an official part of the PDF specification (ISO 32000).
Complexity Score =
(Image Weight × 0.35) // % of file size that is image data
+ (Font Weight × 0.20) // min(100, distinct fonts × 20)
+ (Vector Weight × 0.15) // min(100, avg vector ops/page ÷ 50 × 100)
+ (Transparency × 0.15) // % of pages using transparency/soft masks
+ (Annotations × 0.10) // min(100, avg annotations/page × 20)
+ (Metadata Weight× 0.05) // min(100, metadata bytes ÷ 51,200 × 100)
Optimization Score = 100 − (image penalty + font-subset penalty
+ font-embed penalty + metadata penalty
+ object-stream penalty + uncompressed-stream penalty)| Signal | What it actually measures |
|---|---|
Image Weight | Total bytes of every Image XObject in the file (raw, already-compressed stream size — no re-inflation) divided by total file size. |
Font Weight | Count of distinct font objects referenced anywhere in the document; capped at 100 once 5 or more distinct fonts are present. |
Vector Weight | Average count of path-drawing operators (re, l, c) found per page's content stream, sampled from up to the first 20 KB of each stream. |
Transparency | Percentage of pages whose graphics state dictionary sets ca/CA below 1 or includes a soft mask. |
Annotations | Average annotation count per page (links, form fields, comments, stamps), capped at 100 once average reaches 5 per page. |
Metadata Weight | Combined size of the XMP metadata stream plus Info-dictionary string fields, scaled against a 50 KB reference ceiling. |
Image penalty (≤35) | Share of distinct images whose effective DPI — pixel width ÷ (page width in inches) — exceeds 300 for the page they appear on. |
Font penalties (≤20 + ≤15) | Share of fonts that are not subset (name lacks a six-letter subset prefix) and share that have no embedded font program at all. |
Object-stream penalty (10) | Flat penalty if the file contains no compressed object streams (/Type /ObjStm) — an older, less space-efficient cross-reference format. |
Uncompressed-stream penalty (≤10) | Share of total content-stream bytes stored with no /Filter entry at all. |
Estimated savings are calculated the same way: oversized images assume a 55% recoverable reduction from downsampling and recompression, unsubset fonts assume 60% recoverable from subsetting, uncompressed content streams assume 50% recoverable from standard Flate compression, and non-trivial metadata (over 2 KB) is counted as fully removable. These are estimation heuristics, not guarantees — actual results depend on the compression settings used and the specific tool applied afterward.
FAQ
References & Further Reading