Compress WebP images

Drop WebP files below and get smaller ones back. This helps most with WebPs exported at a high quality by an editor or a CMS. Up to 16 MB a file as a guest or 32 MB with a free account. Free. No account, no watermark.

  • Stays a WebP
  • Transparency kept
  • Original returned if nothing is smaller
Compression Level
None
No compression, only apply settings on image
Lossless
Without any visual change in the image quality
Ultra
Max compression with some quality loss
Smart
Balance between the image quality and compression
Change Format Will allow you to convert images to different extensions
Resize Will allow you to change the width, height or scale of images
Keep EXIF Will allow you to preserve meta data in images
Maximum file size is 16 MB per image and supported formats are: PNG, JPG, JPEG, WEBP, GIF, HEIC, HEIF, TIFF, TIF
Guests get 10 images a day, 10 left today. A free account gets 40 a day.
Delete this image?
The image and its optimized copy will be removed from storage. This cannot be undone.

Rename this image
Choose the name the optimized image downloads with. Its format stays the same.

Uploaded as

Rename the selected images
Each image gets this name and a number, counted in the order they were uploaded. Their formats stay the same.

Share this image
Choose the compression level that suits your images
Level What it promises What happens Pick it when
Lossless
Not one pixel changes in a JPEG, PNG or GIF The file is repacked, never re-encoded. JPEGs get an optimised Huffman table and progressive scan, PNGs a tighter deflate pass, GIFs a lossless gifsicle run. A lossy WebP has no repack step, so it is re-encoded at the highest quality the level allows. A sideways phone JPEG is rotated losslessly on the way through and keeps its colour profile. The one exception to the promise is a PNG or WebP tagged with a wide-gamut profile such as Display P3: its colours are converted to sRGB, so the values change but the picture doesn't. Logos, line art, anything you'll edit again, or when the file is evidence.
Smart
No visible change, targets 40 dB PSNR and a perceptual score of 70 A quality search runs per image and stops at the lowest quality that still clears the PSNR target. That answer is then scored on the SSIMULACRA 2 scale, because an average over every pixel lets a mostly flat picture through at a quality its detail doesn't deserve, and when it falls under 70 the search moves back up until it doesn't. Photos and graphics end up at different qualities because they need different ones; an image that cannot reach the targets inside the quality ceiling is encoded at the ceiling. Almost everything on a website. This is the default for a reason.
Ultra
Smallest file, targets 34 dB PSNR and a perceptual score of 50 The same two-stage search with lower targets. Fine texture softens a little; edges and text stay sharp. Thumbnails, backgrounds, email images, anything shown small or blurred anyway.
None
No compression at all Only the resize, conversion or metadata setting you chose is applied. An untouched upload comes back byte for byte. You only wanted to resize or convert, and quality is someone else's decision.

Measured, not estimated

What compression did to a real WebP

One file, and an honest one: a product shot exported from an editor at quality 92, which is how most oversized WebPs come to exist.

Sample Original Lossless Smart Ultra
Coffee, WebP 1800 by 1200 59 KB WEBP 19 KB 67.9% smaller 16 KB 73.3% smaller 13 KB 77.5% smaller

Showcase product shot, 1800 by 1200. Even the Lossless column is a re-encode here, because a lossy WebP has no lossless repack step. It's encoded at quality 75, the ceiling for a WebP source.

What to expect

A WebP is already compressed. Sometimes too little.

A JPEG can be repacked without touching its pixels. A lossy WebP can't; there's no equivalent trick. So every level here decodes your WebP and encodes it again with cwebp, at its most thorough setting (-m 6 with ten passes) for all but very large images.

Whether that helps depends on how the file was made. Editors and site builders often export WebP at quality 90 or more, far above what the picture needs. Those files shrink a lot. A WebP that a CDN already squeezed to quality 70 won't, and then Iminify gives you your original back instead of a bigger file.

A WebP source is never re-encoded above quality 75. Anything higher spends bytes preserving the first encode's artefacts, not the picture.

What survives

What a WebP keeps when it's compressed

  • Transparency

    The alpha channel is kept at every level.

  • EXIF, when you switch it on

    Stripped by default; attached to the new file when Keep EXIF is on.

  • Exact pixels, even at Lossless

    A lossy WebP is re-encoded at every level. If your WebP is a lossless one and must stay exact, leave it as it is.

  • Animated WebP isn't touched

    Iminify doesn't decode animated WebP. The file comes back unchanged.

When not to

When to leave a WebP alone

  • It came from a CDN or an image service. It has been optimised already, and a second lossy pass costs quality for almost nothing.
  • You still have the original JPG or PNG. Compress or convert from that instead; one generation of loss beats two.
  • It's a lossless WebP of a logo or UI asset. Re-encoding it lossily defeats the point.

How to

Compress a WebP in three steps

  1. 1

    Drop your WebP files

    Change Format stays off, so you get WebP back.

  2. 2

    Pick Smart or Ultra

    Both search for the lowest quality that still matches your file, against different targets.

  3. 3

    Compare, then download

    If a row says the original was kept, nothing smaller could be made at that level.

Questions

WebP compression questions

From the blog

What we've measured so far

We run the encoders on real photos and screenshots and publish the numbers: when WebP beats AVIF, what quality 80 means in each encoder, and how many kilobytes an image on a web page should weigh.

All posts
ComfyUI's Flux Dev example render of a fox-eared girl in a maid dress holding a cake, captioned: 1,215,064-byte PNG to 125,684-byte WebP, and the workflow still loads in ComfyUI.

ComfyUI PNG to JPG loses the workflow. WebP and AVIF can keep it

ComfyUI's Flux Dev example image is a PNG of 1,215,064 bytes, and the two text chunks holding its prompt and workflow take 12,240 of them. The rest is 1024x1024 pixels stored without loss. Across the 92 PNGs in ComfyUI's examples repository that carry a workflow, the text was no more than 3.32 percent of any file, with a median of 0.62 percent. Converting to JPG shrinks the file, but ComfyUI's own loader can't read a workflow back out of a JPG. A WebP or AVIF can keep it, at about a tenth of the size. We took the text-to-image examples of ten models from ComfyUI's examples repository, made smaller copies several ways, and dropped the copies back onto ComfyUI 0.37.0's canvas to see which ones still held the workflow.

6 min read
Bar chart of mozex.dev's image bytes at Lighthouse's phone size: 63.7 KB in 2 files before scrolling, 653.5 KB in 9 files after, and a worked-out 107.1 KB with its own images resized and re-encoded for the phone and the hidden one skipped.

How to find large images on a website: three tools gave us three different lists

On 22 September 2026 we loaded mozex.dev, the site of Mozex Labs, which runs Iminify, at the phone size Lighthouse emulates, and listed its images three ways: Chrome's network log, Lighthouse and a console snippet. Before any scrolling, Chrome had fetched 2 image files, 63.7 KB. After we scrolled to the bottom, it had fetched 9 files, 653.5 KB. Lighthouse's phone runs requested 7 and never the two heaviest, 340.8 KB between them. The browser's own timing data put one image at 0 bytes. So the list you can trust comes from Chrome's Network panel, taken after a scroll. Every method here works on one page at a time, so run it on the pages you care about most.

8 min read
Bar chart of one photograph in bytes: 852,461 as served, against Lighthouse's target of 45,084 at its phone slot and encodes of 47,876 (JPEG), 46,320 (WebP) and 41,735 (AVIF).

Improve image delivery in Lighthouse: what it replaced and how it counts savings

PageSpeed Insights ran Lighthouse 13.5.0 on our home page on 22 September 2026 and flagged "Improve image delivery" in the mobile report: "Est savings of 1,300 KiB". All of it came from one photograph. The fjord shot in our before-and-after comparison is on the page twice, as the 832.5 KiB original and as our own compressed copy at 555.3 KiB. Both files are 1800x1200, and the report says they're displayed at 637x425. Three later runs that day said 1,359 KiB and 364x243. If your old notes say "Serve images in next-gen formats" or "Properly size images", this is where they went: Lighthouse 13 folded four image audits into this one insight. And its savings aren't measured: each figure is arithmetic on bytes and pixels. We reproduced every number in that insight, made the file it asks for, and traced one reason the same page gets two answers.

8 min read

Trim your oversized WebPs

Drop a file. If nothing smaller can be made, you keep your original and lose nothing.

Compress a WebP Open the full tool