About this image compressor & compression calculator
Image Compressor is a free, private image tool that runs entirely in your web browser. Drop one image or a whole batch, set a quality level with the live slider, and watch every file re-encode with its new size, savings percentage and dimensions next to the original. Pick JPG, WebP, AVIF or lossless PNG as the output, downscale to a max width if you want, then download files one by one or grab everything as a ZIP. It also works as a compression calculator: re-encode a representative photo at a few quality levels and formats to find the smallest file that still looks right before you bake that setting into a build pipeline. Because everything happens locally on your device, your files are never uploaded, there is no sign-up, and it keeps working offline. Like every HeroTool by Digital Heroes, it is 100% free with no limits.
JPEG vs WebP vs AVIF: three formats, different jobs
JPEG (1992). The fallback. Universal browser support, universal image-tooling support, the format every CDN and every CMS speaks fluently. Lossy compression with predictable artifact patterns at low quality. Use it as the always-included fallback in a <picture> element. Quality 80 is the production sweet spot; quality 90 for hero images that need pixel-perfect detail.
WebP (2010, ubiquitous since 2020). Google's video-codec-derived image format, roughly 25-35% smaller than JPEG at visually equivalent quality. Universal browser support since 2020. The standard middle layer in modern responsive image pipelines: every <picture> element should include a WebP source. Lossy and lossless modes exist; the canvas API this tool uses exposes the lossy mode only.
AVIF (2019, ubiquitous since 2024). AV1-codec-derived, roughly 20-30% smaller than WebP, so about half the size of JPEG at equivalent quality. Encoding support varies (Chrome and Edge since 2021, Firefox 2024, Safari 16+); decoding support is universal in modern browsers. Ship it as the primary format with WebP and JPEG fallbacks. The encoding cost is much higher than JPEG or WebP, so do it once at upload time, not per-request.
The <picture> pattern. Modern responsive images use a <picture> element with three <source> entries (AVIF, WebP, JPEG fallback) and a final <img> element. Browsers pick the first format they can decode. The fallback <img> is what older browsers and SEO crawlers see; ship a JPEG there for universal compatibility. Google's web.dev image guide has the canonical pattern.
Four jobs this tool covers
Job 1: One-off image optimization before upload. Marketing team has a 4MB hero image and a CMS that doesn't auto-optimize. Drop it here, pick WebP at quality 80, download, upload that instead. The hero loads in a quarter of the time and the Lighthouse score climbs accordingly.
Job 2: Audit your asset pipeline's quality settings. If your build pipeline ships JPEG q90 by default, the WebP q80 output here will tell you what bytes you are leaving on the table. Useful as a periodic spot-check that the pipeline's settings still match the trade-offs you decided up front. Pair it with our Lighthouse Score Checker for the full performance picture.
Job 3: Choose a quality target for a new project. Drop a representative photo from the project and drag the slider between 60, 80 and 90, previewing each pass at full size. The right quality depends on what kind of detail your audience cares about: fashion and luxury brands need higher quality (q85+), utility and commodity brands can ship lower (q60-70). Decide once, set it in the build pipeline, audit periodically.
Job 4: Estimate AVIF savings for a migration plan. Run sample images through with AVIF selected to see the byte savings AVIF would produce against your current JPEG or WebP shipping format. The numbers tell you whether the AVIF migration is worth the build-pipeline complexity. For high-traffic sites where bandwidth is meaningful, the savings usually justify the work; for low-traffic sites the answer can be no.
Frequently asked questions
What's the size difference across JPEG, WebP, and AVIF?
On a typical photo at quality 80, JPEG is the baseline. WebP is roughly 25-35% smaller than JPEG at visually equivalent quality. AVIF is roughly 20-30% smaller than WebP (so about 50% smaller than JPEG). The savings come from better compression algorithms: WebP uses VP8 video compression heritage, AVIF uses AV1 video compression. Browser support: JPEG everywhere, WebP everywhere since 2020, AVIF in all major browsers since 2024. For 2026 web work, ship AVIF with WebP and JPEG fallbacks.
What quality level should I use?
Quality 80-85 is the production sweet spot for photographs: visually indistinguishable from the original to most viewers, with a file 30-50% smaller. Below 60 you start to see compression artifacts in flat color regions and around text edges. Above 90 the marginal quality improvement is invisible while the file gets meaningfully bigger. For hero images that need to be pixel-perfect, ship at 90; for body images and product thumbnails, 80; for grid thumbnails where speed matters more than detail, 60.
Does this work on PNG and animated GIF?
PNG inputs work. Re-encoding to JPEG, WebP or AVIF (lossy formats) means transparency is lost; for images that need to keep transparency (logos, icons), choose the PNG (lossless) output option, which keeps the alpha channel. For animated GIF, only the first frame is processed; for animation conversion, use ffmpeg or a dedicated tool. PNG with no transparency converts cleanly to JPEG with significant savings.
Why does AVIF sometimes fall back to WebP?
Browser support. Chrome and Edge have supported AVIF encoding since 2021, Firefox since 2024, Safari 16+ (2022). On older browsers the canvas.toBlob() call with image/avif returns nothing, so this tool falls back to WebP and shows a notice. Browsers that cannot encode AVIF can still typically decode it, so AVIF as a delivery format works everywhere; only the conversion step is restricted.
What about responsive images and srcset?
This tool generates one variant per file at one size. For production responsive images you typically want 3-4 sizes per format (320 / 640 / 1024 / 2048 wide, for example) for a srcset attribute. Build pipelines like Next.js's <Image> component, Sharp or Squoosh CLI, or Cloudinary handle the multi-size generation. This tool is for the per-variant audit and one-off optimization. For a Squoosh-equivalent in-browser, see the open-source squoosh.app repo on GitHub.
Is the image I upload sent anywhere?
No. Compression happens entirely in your browser using the native canvas API. The page is static HTML; the only network request is the initial page load. Image data never leaves the browser tab. Safe for unpublished marketing assets, customer-supplied media, or any image you would not want uploaded to a third-party service.