Image to WebP Converter
Convert JPG, PNG, GIF and BMP images to WebP, typically 25 to 35 percent smaller at the same visual quality. Batch a folder, tune quality or switch to lossless for flat artwork, and see the exact saving per file. The conversion runs on a canvas in your own browser — nothing is uploaded. Free, no signup.
Add images to convert to WebP
Drag and drop, or click to choose. JPG, PNG, GIF or BMP. Batch supported.
Converted images appear here. Nothing is uploaded — everything happens in your browser.
How to Use This Tool
- Add your images — drag and drop or click to browse. JPG, PNG, GIF and BMP are all accepted, up to 30 at a time.
- Set the quality — 85 percent suits most photos. Switch on lossless for logos, screenshots and flat artwork where edges must stay crisp.
- Check the saving per file — each row shows the original format and size against the WebP result, plus the percentage saved.
- Download — grab files individually or all at once. Files that came out larger are skipped unless you ask to keep them.
About WebP
WebP is an image format developed by Google and now supported by every current browser. Its appeal is straightforward: for the same perceived quality it typically produces files 25 to 35 percent smaller than JPEG, and often much smaller than PNG for the same content. Unlike JPEG it supports an alpha channel, and unlike PNG it offers a genuinely effective lossy mode. That combination means a single format can replace both across most of a website, which simplifies an asset pipeline considerably.
The lossy and lossless distinction matters more in WebP than in most formats because WebP does both well. Lossy WebP uses prediction techniques borrowed from video compression, coding each block by referencing neighbouring blocks and storing only the difference. That is why it beats JPEG, which processes blocks independently. Lossless WebP uses a different algorithm entirely and reliably beats PNG, usually by around 25 percent, which makes it the better choice for logos, icons, screenshots and any artwork with hard edges and flat colour areas where lossy compression produces visible fringing.
Browser support is genuinely solved. Chrome has supported WebP since 2010, Firefox and Edge followed, and Safari added it in 2020, which was the last meaningful gap. Coverage now sits at roughly 97 percent of users worldwide. The remaining friction is not browsers but other software: some desktop image editors, older email clients and a few content management systems still handle WebP badly. If you need a safety net, the HTML picture element lets you offer WebP first and fall back to JPEG automatically, and it costs nothing where WebP is supported.
Two limitations are worth knowing before you convert a folder. First, animated GIFs lose their animation here. WebP as a format supports animation perfectly well, but a browser canvas can only read the first frame of an animated image, so a client-side converter physically cannot preserve the rest. Converting animation needs a dedicated encoder. Second, converting an already heavily compressed JPEG will sometimes produce a larger WebP, because you are re-encoding data that has already had its redundancy squeezed out, and the second pass adds its own artefacts on top of the first.
That second point leads to the most important habit: always convert from the highest quality original you have, not from a file that has already been through a lossy encoder. Every lossy pass compounds, so a JPEG at quality 70 converted to WebP at quality 85 carries all the JPEG artefacts plus new WebP ones, and it may well be bigger. This tool tells you when a conversion made the file worse rather than silently handing it over, and it skips those files from the batch download unless you explicitly ask to keep them.
Pair this with our Image Compressor for JPEG and PNG output, the Image Resizer to cut dimensions before converting, and the Favicon Generator for icon sets.
Frequently Asked Questions
How much smaller is WebP than JPEG or PNG?
For photographs, lossy WebP is typically 25 to 35 percent smaller than a JPEG of equivalent perceived quality, though the exact figure depends heavily on the image. For graphics with flat colour and hard edges, lossless WebP is usually around 25 percent smaller than the equivalent PNG. The savings are largest on images that were not already aggressively compressed. If your source JPEG was already saved at quality 60, there is comparatively little redundancy left for WebP to exploit, and the conversion may produce a bigger file rather than a smaller one.
Is WebP supported in all browsers?
Effectively yes. Chrome has supported it since 2010, Firefox and Edge added it later, and Safari shipped support in 2020, which closed the last significant gap. Current coverage is around 97 percent of users worldwide, and every browser still receiving security updates handles it. The remaining problems are outside the browser: some desktop image editors, email clients and older content management systems handle WebP poorly. For belt and braces on a public site, use the picture element with a JPEG fallback source, which costs nothing where WebP works.
When should I use lossless WebP instead of lossy?
Use lossless for anything with flat colour areas and hard edges: logos, icons, UI screenshots, diagrams, line art, and any image containing text. Lossy compression of any kind produces visible fringing around sharp boundaries, which is exactly where those images live, and it looks noticeably worse than the file size saving is worth. Use lossy for photographs and anything with smooth gradients and natural texture, where the eye cannot detect what has been discarded and the size saving is dramatic. As a rough rule: if the image came from a camera, use lossy; if it came from a design tool, consider lossless.
Why did my animated GIF lose its animation?
Because a browser canvas can only read the first frame of an animated image. The tool decodes your file into an image element, draws it to a canvas and re-encodes it, and at that draw step only one frame exists. This is a limitation of doing the work client-side, not of WebP itself, which supports animation perfectly well and is generally much more efficient than GIF for it. To convert animation you need a dedicated encoder such as gif2webp from the libwebp tools, or a server-side service. For most web use, an MP4 or WebM video is a better replacement for an animated GIF anyway.
Why is my WebP file bigger than the original?
Almost always because the source was already heavily compressed. Lossy encoders work by removing redundancy, and if a previous JPEG pass already removed most of it, a second pass has little left to find while still adding its own overhead and artefacts. The other common cause is lossless mode applied to a photograph, where lossless compression genuinely cannot compete with lossy on that kind of content. The fixes are to convert from the highest quality original you have, and to turn lossless off for photos. This tool flags files that grew and leaves them out of the batch download by default.
Does converting to WebP lose image metadata?
Yes. Because the image is decoded and redrawn through a canvas, all metadata is discarded, including EXIF, camera settings, timestamps, copyright fields and any GPS coordinates. For web publishing this is usually a benefit, since embedded location data in photos taken on a phone is a real privacy risk, and dropping metadata shaves a little more off the file. It is a genuine loss if you need to preserve copyright or provenance information, so keep your originals and treat the WebP files as web derivatives rather than replacements.
Should I convert my whole image library to WebP?
Convert the images that are actually served on your website, and keep the originals. WebP is a delivery format, not an archival one: you want your masters in the highest quality form you have, because every future derivative should come from them rather than from a compressed copy. In practice most teams generate WebP as part of a build step or let a CDN do it on the fly with content negotiation, which is more maintainable than a one-off manual conversion. A manual pass like this is right for a small site, a specific page, or a set of assets you are hand-tuning.
Are my images uploaded anywhere?
No. Files are read locally with the browser FileReader API, decoded into an image, drawn to a canvas and re-encoded to WebP entirely on your own machine. Nothing is transmitted to any server, nothing is logged, and no copy survives closing the tab. That makes the tool safe for client photography, unreleased product shots and anything under NDA. The trade-off is that processing speed depends on your device, so very large batches will be slower than a server-side service would be.