Image to WebP Converter

What is a WebP converter?

A WebP converter takes an image you already have (a PNG, JPEG, GIF, or BMP) and re-encodes it as WebP, the format Google published in 2010 to replace both JPEG and PNG on the web. It exists for one reason. At the same visible quality, WebP files are usually a good deal smaller, and images are almost always the heaviest thing on a page. Smaller images mean a faster Largest Contentful Paint and less bandwidth on mobile. They also mean a Lighthouse audit that stops telling you to serve images in next-gen formats.

This page converts in batch. Drag a folder's worth of images onto the drop zone, or click to browse and select several at once, and each one is converted in turn. The quality slider runs from 10 to 100 in steps of five and starts at 85, which is the setting most people should leave alone. From 80 to 90, WebP is visibly indistinguishable from the source on photographic content. Every converted file comes back as a card showing its original size, its WebP size, and the percentage difference, with a Download button per image and a Download All button once you have more than one. Results stack up as you drop more in, so you can convert the same image at two quality settings and compare the numbers side by side.

When to use it

The clearest case is a small site with a real image problem and no build pipeline to fix it. Take a local business site with forty product photos exported straight out of a phone or a stock library, each one a multi-megabyte PNG or JPEG. It will score badly on every performance audit there is. The fix is smaller files. Drop the whole folder here, download the WebP versions, upload them, and update the image paths. The same applies to a WordPress blog carrying years of oversized uploads. Its media library is full of images that were dropped in at full camera resolution because nothing ever stopped them, and converting the ones that appear on your busiest pages is a couple of minutes of work for a measurable change in load time.

It also fits the handoff points where images move between people. A designer exporting hero images and social cards for a developer can convert them here rather than asking whether the developer's toolchain handles it. A static site generated from Markdown, a landing page assembled in a page builder, a documentation site with screenshots committed straight into the repo: all of them carry images that never pass through an optimiser, because there is nothing in the path to do it. If your team already runs Sharp, ImageMagick, or a CDN that transforms on the fly, keep using those. They resize, strip metadata deliberately, and run on every deploy without anyone remembering. This page is for the images that never get near that, and only for WebP. If the output needs to be PNG, JPEG, or AVIF instead, use the Image to Format tool on this site, which handles all four with the same batch workflow.

How this tool works

Each file goes to the browser's own image decoder, drawn once onto a canvas at the image's natural pixel dimensions, then re-encoded through the canvas blob API with the WebP MIME type and your slider value divided by 100. The re-encode is lossy and the loss is generational. Quality 85 throws away detail the way JPEG does, so a JPEG source loses it a second time on top of what the camera or export discarded, and artefacts compound into soft, blotchy edges. From PNG, a lossless format, there is one generation of loss, and that is where WebP looks best. The encoder belongs to your browser: Chrome, Firefox, and Safari ship their own builds and settings, so the same source at quality 85 can come out a few percent different from one browser to the next. Nothing is resized either. A 4000-pixel-wide photo converts to a 4000-pixel-wide WebP, so if your images are four times larger than the space they display in, converting the format helps far less than resizing would.

The canvas keeps pixels only. EXIF blocks, ICC colour profiles, GPS coordinates, and copyright fields attach to the file rather than the pixels, and none survives. Losing GPS and camera data is usually a feature. Losing the ICC profile matters in a wide-gamut space, since the output is read as sRGB from then on. Losing EXIF orientation is the one that bites: phone photos are often stored sideways with a tag telling viewers to rotate them, this tool does not read or re-apply it, and the WebP it writes carries none, so the result depends on whether your browser applied the rotation while decoding. Check a portrait phone photo before converting a hundred. Transparency does survive. WebP supports an alpha channel and the canvas is not painted with a background colour first, so a transparent PNG logo stays transparent. Animated GIFs go the other way: the canvas captures one frame, so an animation becomes a still image.

The practical ceiling is browser memory. Every image is decoded to an uncompressed bitmap before it is re-encoded, which costs roughly four bytes per pixel: a 6000x4000 photo needs about 96 MB of memory as a canvas regardless of how small the file on disk was. A batch of ordinary web images is fine. A batch of full-resolution camera raws, or a single enormous panorama, can stall the tab or fail outright. A file that cannot be decoded or encoded is logged to the console and skipped, so it does not appear in the results at all. If you dropped in twelve images and got eleven cards back, that is what happened.

All of it happens on your own machine. Nothing is uploaded, and no server ever holds a copy: the file is read from your own disk into memory, converted, and handed back as a download. Most WebP converters you will find work the other way round. They take your image, send it to their backend, convert it there, and give you a link. For a holiday snapshot that hardly matters. For unreleased product photography, a client's brand assets under NDA, a screenshot of an internal dashboard, or anything with a face in it, it matters quite a lot.

Examples

• 1920x1080 photograph saved as PNG, quality 85

  Input

  1.40 MB PNG

  Output

  304 KB WebP (79% smaller)

  The best case, and the reason WebP exists. A photograph stored as PNG is being kept losslessly: every pixel of grain and gradient preserved exactly, which is wasteful for content nobody will inspect pixel by pixel. Lossy WebP at 85 discards detail the eye cannot resolve at normal viewing size. Expect reductions in this range whenever the source is a photographic PNG. Had the source been a JPEG, the same photo would shrink far less, because most of the waste was gone already.

• 1440x900 dashboard screenshot with small text, quality 85

  Input

  67.9 KB PNG

  Output

  42.4 KB WebP (38% smaller)

  A solid but unspectacular win. Screenshots are mostly flat panels and repeated colours, which PNG already handles well, so there is less waste to reclaim than in a photograph. They are also where lossy artefacts show most. Sharp black-on-white text has hard edges, lossy encoders smear energy across them, and at 85 you may see faint haloing around small labels at full size. Push to 95 for anything text-heavy, or keep the PNG.

• 512x512 logo with transparency and a soft shadow, quality 85

  Input

  13.7 KB PNG

  Output

  15.0 KB WebP (9% larger)

  The alpha channel survives. The transparent background is still transparent, which is why WebP can replace PNG rather than only JPEG. The file size did not improve, though, and that is typical: flat brand shapes are what PNG compresses best, so there is little for a lossy encoder to win back. Convert logos for format consistency if you want it, but read the number rather than assuming a saving. And if the artwork is vector underneath, an SVG beats every raster format here by an order of magnitude.

• 400x400 flat two-colour graphic, quality 85

  Input

  1.1 KB PNG

  Output

  1.3 KB WebP (15% larger)

  The honest case where WebP loses outright, and the card will show a positive percentage instead of a negative one. PNG compresses long runs of identical pixels extremely well, so a small flat-colour graphic is already close to optimal, and WebP's container and encoder overhead is a fixed cost a 1 KB file cannot amortise. Below a few kilobytes, and for anything that is large areas of solid colour with hard edges, keep the PNG. Converting a whole folder without reading the numbers is how people ship a slower site than they started with.

Frequently asked questions

• Is WebP better than JPEG and PNG?

  It depends on the source, and the honest answer is that it sometimes loses. Against a PNG holding a photograph, WebP wins overwhelmingly, often 70-80%, because it can be lossy where PNG cannot. Against a JPEG already saved at a sensible quality, the gain is modest and comes with a second generation of loss. Against a small flat-colour PNG or a simple logo, WebP frequently produces a larger file. Convert, then read the number on each card before you commit.

• Do all browsers support WebP?

  Effectively yes. WebP works in Chrome, Edge, Firefox, Opera, and Safari 14 and later, which covers every browser released since late 2020 and well over 95% of live traffic. The gaps are outside browsers. Some email clients still do not render it, and older desktop software, print workflows, and legacy CMS uploaders may reject the format. For a public website you can serve WebP directly. For an email campaign, or a file someone will open in an old application, stay with JPEG or PNG.

• What quality setting should I use for WebP?

  Start at the default of 85 and only move if you have a reason. Between 80 and 90, WebP is visually indistinguishable from the source for photographic content while cutting most of the file size, which is why that band is the standard recommendation. Go to 95 for screenshots, diagrams, or anything with fine text where lossy edges show. Drop toward 60-70 only for large decorative background images nobody will look at closely.

• What is the difference between this and the Image to Format tool?

  This page does one thing: it converts images to WebP. The Image to Format tool is the multi-format version, with the same batch drag-and-drop and the same in-browser conversion, but you pick the target from WebP, PNG, JPEG, or AVIF. Use that one whenever the output needs to be something other than WebP: converting a WebP back to PNG for a program that will not open it, flattening to JPEG, or comparing formats before you commit. Stay here when WebP is the decision and you would rather skip the dropdown.

• Could you automate this across our whole image library?

  Yes, and it is a normal piece of work for Zinc Online Solutions. Converting images by hand is fine for a page or two. It stops making sense somewhere around the fiftieth file, or the first time someone uploads a 6 MB photo to your CMS after everything was already tidied up. At that point the job belongs at the upload step or in the deploy, resizing and converting automatically and leaving the originals alone. We build the internal tooling that moves it there. Tell us where your images come from and who is doing this by hand today, and we will price the version nobody has to remember to run.