Image to WebP Converter
Converts a PNG or a JPEG to WebP in this browser tab and reports exactly how many bytes it saved — or that it did not, which for small flat images is the honest answer. The decoding and the encoding both run on your own machine.
How it works
What this works out
How much smaller the same picture is as a WebP, and whether the trade is worth making. The answer is two figures — the size of the file it produced, and the difference against the one you gave it — and the difference is reported in whichever direction it actually went.
The method
The file is identified from its own first bytes rather than from its name, then decoded to raw pixels, then re-encoded. Three separate codecs are involved and all three run in this tab: libpng or mozjpeg to get the pixels out, libwebp to put them back.
Quality is passed to libwebp unchanged. Lossless is passed as a level rather than a flag, which is what libwebp expects — handing it the checkbox directly would silently mean “lossy” every time.
Why a library here, when the JPEG converter hand-writes its own
The PNG to JPEG converter on this site implements both of
its codecs from the specifications, and its page explains why at length. Two of
those three reasons apply here just as strongly: the browser’s own quality is
documented as a hint rather than a contract, so one setting gives a different
file in every engine, and a tool whose entire readout is a file size cannot have
that size depend on which browser you opened.
The difference is the encoder. A JPEG encoder is a weekend of careful work against a published table. WebP is intra-frame VP8 — a transform, a quantiser and a boolean-arithmetic entropy coder — and a hand-written one would be slower and worse than libwebp for no benefit anyone could point at.
So this page ships libwebp, libpng and mozjpeg compiled to WebAssembly. They are Apache-2.0, they run on your machine, and they load only when you convert something rather than when you arrive: about 340 KB that costs nothing until it is used. What survives unchanged is the part that mattered — the conversion is exactly reproducible, identical in every browser, and needs no network at all.
Before you read on
A 69-byte PNG holding a single pixel is converted to WebP. What comes out?
68 bytes: one byte smaller, which is to say no saving whatever. Both files are almost entirely container, and there is nothing in a single pixel left to compress. It is not a contrived case — it is the smallest real file to hand and it is asserted in this tool's test file, so this page and the code cannot drift about what happens at the bottom end. Scale up and the picture reverses completely: a photograph at quality 80 is usually twenty-five to thirty-five per cent smaller than the equivalent JPEG.
A worked example
A 69-byte PNG of a single pixel converts to a 68-byte WebP: one byte smaller, which is to say no saving at all. That is not a contrived case — it is the smallest real file to hand, and it is asserted in this tool’s test file, so this page and the code cannot drift about what happens on a file too small to compress.
Scale it up and the picture changes completely. A photograph at quality 80 is usually twenty-five to thirty-five per cent smaller than the equivalent JPEG, and a flat-colour screenshot saved losslessly is usually smaller than the PNG. The rule of thumb is that WebP wins on everything except files that were already too small to have anything left to compress.
What the numbers mean
WebP size is the file offered below, in units of 1,024 bytes.
Saved compares it against the file you chose. A negative saving is stated as plainly as a positive one, because the files where WebP loses are exactly the files where a reader most needs to be told.
How it is done
- Read the first bytes of the file and decide what it actually is. A PNG begins with the signature 89 50 4E 47; a JPEG begins with FF D8 FF. The file name is never consulted, because a name is a claim.
- Decode it to raw RGBA pixels — libpng for a PNG, mozjpeg for a JPEG, both compiled to WebAssembly and both running here rather than on a server.
- Encode those pixels as WebP with libwebp at the chosen quality. With lossless on, quality is ignored entirely, because libwebp switches to a different encoder that reproduces every pixel exactly.
- Compare the two file sizes and report the difference in whichever direction it went.
What it assumes
- Quality is libwebp's own scale, not the browser's. The same number produces the same file in every browser, because the encoder ships with the tool rather than being borrowed from the engine.
- Lossless ignores the quality setting completely. That is libwebp's behaviour rather than a simplification made here.
- Colour profiles are not carried across. An ICC profile in the source is dropped and the WebP is written as plain sRGB, so a wide-gamut photograph comes out flatter than the original.
- Animated GIF, AVIF, HEIC, TIFF and SVG are not read. It takes a PNG or a JPEG, one file at a time, up to 32 MB.
- EXIF orientation is not applied, so a photograph a phone tags as rotated comes out in the orientation its pixels are actually stored in.
Common questions
Is the image I convert uploaded anywhere?
No. The file is read in this browser tab and both the decoding and the encoding happen in a worker on your own machine. There is no server to send it to, and the automated test for this page asserts that no request leaves it while the tool is used.
Why did my WebP come out larger than the original?
Because the WebP container and headers cost a fixed amount, and on a small or very flat image that overhead is more than the compression saves. It happens most with icons, screenshots of solid colour, and anything already well compressed. The tool says so rather than quietly reporting a saving, and on those files the right answer is to keep what you had.
Should I choose lossless or lossy?
Lossy for photographs; lossless for anything with flat colour, sharp edges or text — logos, diagrams, screenshots. Lossless WebP typically beats PNG by twenty to thirty per cent on exactly that kind of image, and lossy WebP beats JPEG at a matched quality. Quality is ignored when lossless is on.
What quality should I choose for a photograph?
Around 80, which is where libwebp's own documentation puts the useful part of the curve. Below about 60 the artefacts become visible on skin and sky; above about 90 the file grows quickly for a difference most people cannot see on a screen.
Is WebP safe to use everywhere now?
In browsers, yes — Chrome, Firefox, Safari and Edge have all supported it for years. The remaining risk is other software: some desktop editors, email clients and content systems still will not open it, so keep the original if the file has to go somewhere that is not a web page.