WebP Converter

Convert JPEG, PNG, or WebP sources to WebP. Up to 5 images per batch.

Drag & drop images here

or tap to browse (PNG, JPEG, WebP, SVG)

Up to 5 images per batch, 25 MB each

Target Format

webp

Quality

80%

Up to 5 images per batch

Load your sources

PNG, JPEG and WebP are all accepted, and you can mix them in the same batch of five. Each file is verified by its actual header bytes before it is queued.

Tip: Mixing formats in one batch is fine. The encoder does not care what the source was once it has been decoded to pixels.

Choose a quality point

80 is the default and suits most work. Photographic material tolerates 70 to 75 without complaint; flat colour and text-heavy graphics want 85 or higher to avoid ringing around edges.

Tip: If you are matching an existing JPEG, start at the same number. WebP at quality 80 is roughly comparable to JPEG at 80.

Encode and download

Files are processed two at a time, collected into a ZIP in the browser, and saved with their original names and a .webp extension.

Tip: Compare one output against its source at full zoom before you convert the rest of the folder.

Lossy and lossless in one format

WebP carries two distinct compression engines under a single container, so the same format handles a photograph and a flat-colour logo well. You are not forced to change format when the content changes.

Transparency without the PNG tax

The alpha channel works in lossy mode, which PNG cannot offer and JPEG does not have at all. A cut-out product image with a soft edge stays clean at a fraction of the size.

Runs locally, works offline

Encoding uses the canvas encoder built into your browser. Once the page has loaded there is no further network activity, and nothing about your images is transmitted anywhere.

Batch of five, two at a time

A batch accepts five files and the worker pool encodes two concurrently. That keeps peak memory bounded while still using more than one core on anything but the smallest machines.

Quality mapping that resists waste

The slider value is mapped rather than passed straight through, and the interface flags settings above 90 where WebP begins spending disproportionate bytes on detail you cannot see on screen.

Universally decodable today

Chrome, Firefox, Edge and Safari 14 onwards all decode WebP natively. For the rare client that cannot, a picture element with a JPEG or PNG source is a three-line fallback.

Frequently Asked Questions

How much smaller will my files actually get?+

It depends entirely on the source. PNG screenshots and UI exports routinely drop by ninety percent or more. JPEG photographs typically drop twenty to thirty percent at matched quality, because you are re-compressing something already compressed.

Should I use lossy or lossless WebP?+

Lossy for anything photographic or with gradients, which is most content. Lossless only when you genuinely need the exact pixels back, such as a diagram containing hairline strokes or single-pixel text that will be read at 100 percent zoom.

Why is my re-encoded WebP bigger than the original?+

You have probably set the quality higher than whatever the source was encoded at. Re-encoding cannot recover detail that was already discarded, but it will happily spend bytes trying to preserve the compression artefacts. Lower the slider and try again.

Can I convert five images and then five more?+

Yes. Clear the batch after each ZIP and load the next five. The limit is per batch, not per session, and there is no counter or quota behind it.

The cap exists because decoded bitmaps are large in memory. A five-image ceiling keeps the tool stable on phones as well as desktops.

Does WebP support animation?+

The format does, but this tool does not produce animated WebP. It converts still images only. An animated GIF dropped here would be converted using its first frame.

Is the quality slider the same scale as JPEG quality?+

Close enough to use as a starting point. WebP at 80 and JPEG at 80 land in a similar visual place, though WebP will usually get there in fewer bytes. Treat the numbers as comparable rather than identical.

Format Comparison

Feature Specification	WebP conversion	Alternative
Compression approach	Block prediction plus transform	Independent block transform
Transparency	Full alpha, lossy or lossless	None
Degradation at low bitrate	Softening	Visible 8x8 blocking
Browser support	Every current browser	Every browser ever made
Encoding cost	Slower to encode	Very fast

Technical Overview & Specifications

Deep dive into WebP conversion architecture and processing.

Show Details

Platform Overview

WebP is the format that finally replaced the awkward JPEG-or-PNG decision that web developers had been making since the nineties. Before it, you picked JPEG and gave up transparency, or you picked PNG and gave up compression. WebP does both: it has a lossy mode built on the intra-frame coding from the VP8 video codec, a separate lossless mode with its own entropy coder, and an alpha channel that works in either one. Google published it in 2010 and it took about a decade to become genuinely safe to deploy, which happened the moment Safari 14 shipped in 2020. Today every browser anyone actually uses can decode it, and it is the sensible default target for almost any image you are putting on a page.

This page takes mixed sources, up to five files per batch, and encodes them all to WebP in the browser. Photographs coming from JPEG will shrink somewhat, usually by twenty to thirty percent at matched visual quality, though the gain is modest because you are re-compressing data that has already been through a lossy pass. The dramatic wins come from PNG sources, where the drop is often ten to one or better. Screenshots, exported UI mockups, charts with soft gradients, product shots on white: all of these are stored terribly by PNG and beautifully by WebP. If your files are already WebP and you only want them smaller, drop them here and pull the quality slider down rather than reaching for a different tool.

How WebP earns its size advantage

Lossy WebP borrows the intra-frame prediction machinery from VP8. Before compressing a block of pixels it predicts what that block should look like from the neighbouring blocks already decoded, then stores only the difference between the prediction and reality. On a photograph with smooth gradients those differences are tiny, which is why the format does so well on exactly the content PNG handles worst. JPEG has no comparable prediction step: it transforms each 8 by 8 block independently with a discrete cosine transform and quantises the coefficients. That independence is why JPEG produces visible blocking when you push the quality down, and why WebP degrades more gracefully at the same file size.

In this tool the encode happens through the browser canvas API rather than a bundled encoder. The image is decoded onto an OffscreenCanvas inside a Web Worker, any scaling you have configured is applied at that point, and the canvas is asked for a WebP blob at the mapped quality. Using the browser encoder means the binary you download is small and the encode is fast, since it runs through the same native code path the browser uses everywhere else. The trade-off is that fine-grained encoder controls, such as the method or filter strength you would get from a full libwebp build, are not exposed. For web delivery work that ceiling is rarely the thing standing between you and a smaller file.