Image compression calculator. JPEG, WebP, AVIF.
Drop an image. We re-encode at six quality levels across JPEG, WebP, and AVIF formats and show file size + savings percentage for each. Side-by-side preview. Pick the variant, download. Browser-only.
Drop an image. We re-encode at three quality levels across JPEG, WebP, and AVIF (where supported) and show byte size + savings percentage for each. Click any variant to preview at full size. Download the variant you want. Pure canvas API — no upload.
Privacy: compression happens in your browser. Nothing is sent or logged.
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 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. ~25-35% smaller than JPEG at visually equivalent quality. Universal browser support since 2020. The mandatory middle layer in modern responsive image pipelines — every <picture> element should include a WebP source. Lossy and lossless modes; canvas API exposes the lossy mode only.
AVIF (2019, ubiquitous since 2024). AV1-codec-derived. ~20-30% smaller than WebP, so roughly half the size of JPEG at equivalent quality. Encoding support varies (Chrome + Edge since 2021, Firefox 2024, Safari 16+); decoding support is universal in modern browsers. Ship as the primary format with WebP and JPEG fallbacks. The encoding cost is much higher than JPEG/WebP — 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 here, pick the WebP q80 variant, download, upload that instead. The hero loads in 25% of the time and 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 in this tool will tell you what bytes you're 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 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, look at quality 60 vs 80 vs 90 side by side. The right quality for your project depends on what kind of detail your audience cares about — fashion / luxury brands need higher quality (q85+), utility / commodity brands can ship lower (q60-70). Decide once, set in build pipeline, audit periodically.
Job 4: Estimate AVIF savings for a migration plan. Run sample images through to see the byte savings AVIF would produce vs your current JPEG/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.
Six questions users ask.
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 ~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 fallback and JPEG fallback.
What quality level should I use?
Quality 80-85 is the production sweet spot for photographs — visually indistinguishable from the original to most viewers, file size 30-50% smaller than the original. 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 — they get re-encoded to JPEG/WebP/AVIF (lossy formats), which means transparency is lost. For images that need to keep transparency (logos, icons), use PNG-to-WebP or PNG-to-AVIF in their lossless modes — the canvas API doesn't expose lossless WebP/AVIF easily, so we don't surface that path here. 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 is AVIF sometimes missing from results?
Browser support. Chrome / Edge supported AVIF encoding since 2021, Firefox since 2024, Safari 16+ (2022). On older browsers the canvas.toBlob() call with image/avif returns null and we omit it from the results. If you don't see AVIF, your browser doesn't support encoding it — note that browsers that don't encode AVIF can still typically decode AVIF, so AVIF as a delivery format works everywhere; only the conversion tool is restricted.
What about responsive images and srcset?
This tool generates one variant of 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 / Squoosh CLI, or Cloudinary handle the multi-size generation. This tool is for the per-variant audit and one-off optimization. For 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 wouldn't want uploaded to a third-party service.
Published · Last updated .