Convert JPG to WebP
Smaller files for the web — and an honest number for what it actually saved.
Runs in your browser0 bytes uploadedSmaller files for the web — and an honest number for what it actually saved.
Runs in your browser0 bytes uploadedDrop your JPG files here
or paste Ctrl+V
Nothing is uploaded. The pictures are re-encoded as WebP inside this tab, and you see the estimated saving before you commit to it.
Got a .webp file that nothing will open? Convert WebP to JPG.
One reason, and it is a good one: page weight. WebP at a matched visual quality is typically 25 to 35 percent smaller than the JPEG it came from, and images are usually the largest thing a web page ships. Cutting a third off them moves the numbers that matter — Largest Contentful Paint, the amount of data a phone on a bad connection has to pull down, the bandwidth bill. Every browser in current use has read WebP for years, so serving it is no longer a compatibility gamble.
That is the case for the web. It is not a case for converting your photo library. A WebP sitting on your disk is harder to open in desktop software than the JPEG it replaced, and the saving buys you nothing you can feel. Convert what you are about to publish.
A JPEG has already thrown detail away. That is what lossy compression is: the encoder decided which information the eye would not miss and discarded it permanently. When you re-encode that file as WebP, a second encoder makes the same kind of decision again — this time about an image that is already missing pieces, and partly about the artifacts the first encoder left behind.
This is generation loss, and no setting avoids it. Quality 100 does not avoid it; it just spends a lot of bytes preserving the first encoder's mistakes faithfully. In practice one generation at quality 80 is invisible on a photograph, which is why this is a reasonable thing to do at all. Repeated round trips are not invisible. If you have the original — the RAW, the PNG export, the file straight out of the camera — encode WebP from that instead and skip a generation entirely.
WebP does have a lossless mode, and this tool deliberately does not offer it. From a JPEG source it cannot help you: lossless WebP would faithfully preserve the detail your JPEG has left, artifacts and all, in a file substantially larger than the JPEG you started with. You would be paying more bytes for exactly the same picture. A control that cannot improve your outcome should not be on the screen.
Lossless WebP earns its place elsewhere — screenshots, logos, line art, anything that came out of a lossless format to begin with and has hard edges rather than photographic gradients. If that is what you have, you are in the wrong direction of the wrong tool; compare the formats in JPG vs PNG first.
Because 100 on a JPEG source almost always produces a file larger than the one you began with, which is the opposite of the reason you are here. The encoder spends its budget reproducing compression artifacts at high fidelity. Eighty is the point where the second generation stops being visible on photographic material and the saving is real. Below about sixty you will start to see it on skies and skin.
The estimate above the button is measured rather than guessed. Sixteen tiles are sampled from across each picture at full resolution, assembled into one sheet, and actually encoded as WebP at the quality you have chosen. The bytes per pixel that come back are multiplied by the output size. It is still an estimate — an image with unevenly distributed detail will move the number — but it comes from a real encode of your real pixels, not from a rule of thumb about averages.
If the estimated saving is under ten percent, the tool says so before you convert. That is the case where the trade goes bad: you spend a generation of quality and gain almost nothing, and you end up with files that some of your tools cannot open. It happens when the source JPEG was already compressed hard — an image that has been through an upload pipeline once or twice usually has been.
And if the file comes out larger, the receipt says larger, in the same plain numbers. The suggestion is to lower the quality and run again rather than to accept the result, and the pictures stay loaded so re-running costs one click. If what you actually need is a specific file size rather than a specific format, compressing to a target size is the tool that solves that directly. And if you are dealing with the opposite problem — a downloaded .webp that nothing on your machine will open — the conversion runs the other way at WebP to JPG.
Everything here runs in this tab. Your browser already decodes JPEG and already writes WebP; there is no server in the path, no upload endpoint, and no queue. The trade-off is that no metadata survives the trip: a canvas writes pixels and nothing else, so EXIF, color profiles and copyright fields are dropped. For images headed for a web page that is usually welcome, but keep your originals.
Yes, a little, and it is worth understanding why. A JPG has already discarded detail permanently. Re-encoding it as WebP discards a second time, on top of the first — that is generation loss, and no setting avoids it. The result is usually indistinguishable at quality 80 or above, but converting back and forth repeatedly will visibly degrade an image.
Because it would be a setting that cannot help you. WebP does have a lossless mode, but a JPG has already thrown detail away — lossless would faithfully preserve what is left in a file substantially larger than the JPG you started with. Lossless WebP earns its place on screenshots and graphics, not on photographs that came out of a lossy format.
Typically 25 to 35 percent at the same visual quality, but it depends entirely on the picture. Photographs with a lot of fine detail save less; flat images with large areas of similar color save more. The tool estimates the saving before you convert, and tells you when the answer is "barely any" so you can decide it is not worth it.
Effectively yes — Chrome, Firefox, Edge and Safari have all supported it for years. The remaining problem is not browsers but software: some older desktop applications, print workflows and upload forms still reject WebP, which is why the conversion in the other direction is the more common request.