Shrink the photos embedded inside a PDF without touching its text, fonts or layout. Quality control, a resolution limit, and a clear per-image breakdown. Nothing leaves your device.
In-place
Text and Layout Untouched
Reported
What Was Skipped, and Why
No Larger
Ever, Only Kept As Is
Private
No Uploads
Drop your PDF here
One PDF at a time
Your file never leaves this device
Only the embedded images that can be safely recompressed are touched. Everything else is reported, never guessed at.
Detection before compression
Every embedded image is found and classified first, so you see exactly what will be compressed before anything happens.
Quality and resolution control
A quality slider for JPEG recompression, and an optional cap on the longest side for images inserted far larger than they need to be.
Per-image breakdown
See the before and after size of every image individually, and the total reduction across the whole document.
Text, fonts and layout untouched
Only image objects are ever rewritten. Everything else on every page stays exactly as it was.
What gets skipped, and why
Scanned bi-level images, CMYK images and a few other edge cases are left alone on purpose, each with its own clear reason shown.
Never larger, only kept as is
If recompressing an image would make it bigger, the original is kept and reported as already optimized instead.
Shrink a photo-heavy report for email
A report with a dozen embedded photos can easily exceed an email attachment limit. Recompressing the images alone often solves it.
Reduce a marketing PDF for a website download link
A brochure or one-pager exported at print resolution is usually far larger than it needs to be for a simple website download.
Clean up a PDF exported from a design tool
Design and presentation software often embeds images at full resolution regardless of how small they appear on the page.
Check what is actually taking up space
The per-image size breakdown makes it obvious which specific images are responsible for most of a PDF's file size.
Scanned bi-level images (JBIG2, CCITT)
Specialized formats for scanned black and white pages. Decoding them reliably in a browser is not something this tool attempts, so they are left exactly as they are rather than risking a broken page.
CMYK images
Detected directly, and through the more common real world case, an embedded ICC color profile reporting 4 channels. Left untouched rather than approximately converted, since that conversion can shift color at print time.
Non-JPEG raw bitmaps
Reconstructing pixels from an arbitrary raw color space and bit depth is real additional risk for comparatively little benefit, since most oversized PDFs are bloated by embedded JPEGs, not raw bitmaps.
Images with a transparency mask
Replacing an image without also correctly handling its separate mask object risks breaking the transparency entirely, so these are left alone.
A PDF page does not store an image's pixels directly inside its own content. Instead, the page contains an instruction that essentially says draw the image that lives in object 47 at this position, and object 47 is stored separately elsewhere in the file as what is called an image XObject. Every place across every page that uses that image points at the same object, rather than each place storing its own copy. That structure is exactly what makes replacing an image safe and precise. Recompressing an image means swapping out what object 47 contains, and every page that already pointed at object 47 automatically shows the new, smaller version, with no need to find and rewrite the page content itself.
This is also why the rest of the document is guaranteed to stay untouched. Text is stored as its own separate kind of object, fonts are embedded as their own objects, vector graphics and page dimensions are unrelated structures entirely. None of that is walked or modified by this tool, only the specific objects that are image data and that pass the safety checks described above ever get rewritten.
It would be technically possible to attempt every embedded image regardless of its format, decoding a scanned fax-style image with a fragile, unofficial method, or converting a CMYK photograph to RGB with an approximate formula. Both of those would sometimes work and sometimes produce a subtly broken or discolored result, and there is no way to tell which case you are in until after the fact. Skipping those categories entirely, and saying so plainly in the results, is the more honest choice. A PDF you can trust the output of is worth more than a slightly bigger file that compressed everything, including the images that were never safe to touch in the first place.
If your PDF is a scanned document and this tool reports most of its images as skipped, that is expected rather than a bug, and a general purpose PDF tool that promises to handle every possible embedded format is making a promise it likely cannot keep reliably either. For photo-heavy PDFs, brochures, reports, anything built from embedded JPEGs rather than scanned pages, this tool handles the common case directly and the results are usually substantial.
Many scanned documents store their pages using JBIG2 or CCITT encoding, specialized formats built for black and white scanned pages rather than photographs. Decoding those formats reliably in a browser is not something this tool attempts, since getting it wrong risks a broken or unreadable page, so those images are left exactly as they were rather than guessed at. If a PDF is mostly photographs embedded as JPEG, the reduction is usually substantial.
No. Only the embedded raster images that qualify are touched. Text, fonts, vector graphics, page size, and the position of everything on the page stay exactly as they were, since a PDF page references an image as a separate object rather than storing it inline, replacing that object does not change anything about how the rest of the page is built.
An image that was already compressed efficiently, or is small to begin with, may not have much room left to shrink at a given quality setting. This tool never makes an image larger to force a reduction, if recompressing would produce a bigger file than the original, the original is kept and that image is reported as already optimized rather than replaced.
Images using CMYK color, the color model print production relies on, are detected and left untouched rather than approximately converted, since that conversion is exactly the kind of change that can look fine on screen and print wrong. If your PDF is intended for professional printing, treat any image this tool did compress as screen-safe, and check the per-image summary for anything reported as CMYK and skipped.
JPEG images embedded in the PDF, which covers the large majority of PDFs that are unexpectedly large because of embedded photographs. Uncompressed or Flate-compressed raw bitmaps, JPEG2000 images, and images with a transparency mask are currently left untouched rather than risking an incorrect result. Every image the tool finds is reported either as compressed or skipped with a specific reason, never silently ignored.
No. Reading the PDF, recompressing its images, and rebuilding the file all happen entirely in your browser. Your file never leaves your device. You can disconnect from the internet after loading the page and the tool still works completely.
