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

Balance between the image quality and compression

Output format

Auto tries every format your image can be saved as and gives you the smallest one

Resize

Change the width, height or scale of every image you upload

Original Dimensions Percentage
px
px

Set one side to keep the proportions, or both for an exact size.

Percentage
%

Size limit

Fit every image under a file size, for a form or a site with an upload limit

Any size Under a size
KB

Saved as JPG, WebP or AVIF. When quality alone can't get there, the image is made smaller to fit.

How the size limit works

Responsive image set

Pro

The image at several widths, with a srcset to paste into your page, so each screen loads the size it needs

One size Responsive set
px

Up to 8 widths, each in the format and at the level of the result. A width wider than the image stops at its own width, so nothing is enlarged.

How responsive sizes work

See Pro
Keep EXIF Keeps details such as the camera, the date and the location in each file. Leave it off to remove them and save space.
Write alt text with AI Describes each image for screen readers and search engines, and suggests a file name
Alt text language
No language matches
English
Spanish
French
German
Italian
Portuguese
Dutch
Polish
Swedish
Turkish
Russian
Ukrainian
Arabic
Persian
Hebrew
Hindi
Indonesian
Vietnamese
Thai
Japanese
Korean
Simplified Chinese
Traditional Chinese
Rename files Downloads take the suggested name instead of the one you uploaded

Pro
Uploading a zip comes with Pro: the browser opens it and uploads its images in the folders they sat in, and the zip of the results keeps them. On your plan, unzip it and drop the images here. How folders and zips work
See Pro

Up to 16 MB per image PNG, JPG, WEBP, GIF, HEIC, TIFF, or a ZIP of them on a paid plan

Guests get 10 images a day, 10 left today. A free account gets 40 a day and 7 days of Pro.

Upload a folder, or a zip

Pro

Pick a folder and every image in it uploads, with the folders inside it, and Download Selected gives them back in the same folders. A zip of images dropped on the box works the same way, opened in your browser.

How folders and zips work

See Pro
Auto-start
On, each image starts compressing as soon as it uploads. Off, images wait in the box so you can check the settings, then start together.
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
AI alt text
Alt text

Paste it into the alt attribute of the image on your page.
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. Without a resize or a conversion every pixel comes back as it was: the file only loses its metadata, and with Keep EXIF on it 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. Every frame comes back as it was, and only the metadata goes, unless Keep EXIF is on. A resize of one is refused, because only its first frame would survive it.

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

    Format stays on Original, 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 is marked Already Optimized, nothing smaller could be made at that level.

Questions

WebP compression questions

Next

Related tools

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
Two rows of seven squares, one per test post. After the default wp media regenerate, four squares are red and read 404 and three read 200; after --skip-delete and the rewrite, all seven read 200.

Convert your existing WordPress images to WebP without a plugin: what regenerate breaks

On a WordPress 7.1.4 test site, one filter and wp media regenerate turned the resized copies WordPress makes of five full-colour (4:4:4) photographs into WebP files with 62.5% of the JPEG copies' bytes. All 25 WebP copies, five sizes of each photograph, also scored lower. The filter and regenerate also left four of our seven test posts pointing at copies WP-CLI had just deleted, and took the srcset off all seven inserted images that had one. The version below leaves no address broken and gives six of those seven their srcset back: the filter, regenerate with one flag, and a rewrite that changes an address only where a WebP exists. The recipe as printed needs WP-CLI and a shell on the server.

8 min read
Bar chart of bytes Chrome downloaded at phone size for five 4K JPEGs on a Next.js static export page: 55.2 MB as they are, 10.2 MB as Smart JPG at full size, 1.29 MB at 1200 px wide, 767 KB through next-image-export-optimizer.

Next.js static export images: the default loader breaks them and unoptimized ships the original

We built a page with five photographs in a Next.js 16.4.3 App Router app, set output: 'export', left the image settings alone, and next build finished with exit code 0. In Chrome none of the five images loaded: every src pointed at /_next/image, an endpoint a static export doesn't contain. Setting images: { unoptimized: true } fixes that, and the export then serves the file you put in public/. Chrome at phone size downloaded 2.4 MB for five 1800 px photographs, and 55.2 MB when the same page held five 4K Gemini JPEGs. This post compares that flag, next-image-export-optimizer and resizing the files first by what Chrome downloaded at phone size and at desktop size. The table is in the second section, and the choice we'd make follows the three options.

7 min read
Iminify blog cover on a blue gradient with a pixel pattern: "Should you compress before your CDN does?"

Should you compress images before your CDN re-encodes them? Measured through Next.js, wsrv.nl and Photon

The Fjord, one of our five test photographs, is an 852,461-byte JPEG, the master every score below is measured against. Iminify's Smart level makes it a 568,598-byte JPEG. We sent both through Next.js 16.4.3's image optimizer at its default, WebP at quality 75. Next's WebP of the master weighed 321,790 bytes and scored 66.98 against the master on SSIMULACRA 2, where 100 means no difference from the master. Its WebP of the Smart file weighed 314,578 bytes and scored 64.30: 2.2 percent fewer bytes for 2.7 points. Should you compress before a CDN or optimizer re-encodes your image? In our tests, on five JPEG photographs through Next and wsrv.nl, only losslessly. A lossless repack, which made our uploads 2.4 to 5.6 percent smaller, changed nothing in 80 of 80 Next responses. And in 40 of 40 comparisons at no more bytes, asking Next for a lower quality setting scored higher than the lossy first pass. If nothing re-encodes after you, compress first.

7 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