Convert JPG to WebP
This tool does not convert your JPG blindly. It encodes it in both formats, measures both against your source and returns the smaller result that holds your quality target. Often that is WebP — but not always, and with JPEGs that are already well compressed, the source itself sometimes wins. Which format came out, and with which measured value, is shown with the result.
Drag an image here
or paste from the clipboard (Ctrl+V / ⌘V)
JPEG, PNG or WebP · the image stays on your device
Our own test series: 13 JPEG sources
Our test corpus holds 13 JPEG sources. At a quality target of SSIM ≥ 0.98, the tool returns 10 of them as WebP; 3 stay JPEG. Across all 13 together the data drops by 26.5 %, from 14.8 MB to 10.9 MB.
The 10 images that changed save a median of 35.4 %. The 3 remaining JPEG results save a median of 14.3 %.
| JPEG sources in the corpus | 13 |
|---|---|
| returned as WebP | 10 |
| returned as JPEG | 3 |
| of those, handed back unchanged | 0 |
| Saving across all sources | 26.5 % |
| Median per image | 31.3 % |
| Lowest measured quality value | 0.98006 |
These runs set no target resolution and no target size. What is measured is therefore only what the format change brings at unchanged dimensions. A preset with a target width achieves more — how much is not stated here, because it was not measured here.
Based on the fixed corpus runs of this project: 20 images, quality target SSIM ≥ 0.98, measured under Node with the codec versions from the manifest. Not counted: wide-gamut-p3.jpg — Decision 44: Display P3 profile, decoded without color conversion under Node. Its SSIM under Node is not the one the product delivers; the image tests ICC detection and counts in no statement about quality or size.
The values on this page, with their origin
| Preset | Website / blog image (web) |
|---|---|
| Target resolution | up to 1920 px wide |
| How the dimensions are read | Budget: smaller images stay unchanged, larger ones are fitted |
| Allowed formats | WebP, JPEG, PNG — chosen by measurement |
| Quality target | SSIM ≥ 0.98 |
| Metadata | removed (EXIF, GPS) |
| Origin of the values | Project value, no outside source |
| Source | none — the value comes from this project’s specification |
| Last checked | – No check date needed |
The width 1920 is the default value in the project specification 7.2. There is no platform documentation for it — the number is a setting of this project, not an outside requirement. The width is a budget, not a requirement — hence `fit: "max"`.
Platforms change their requirements without notice. That is why every check expires after 90 days and then shows as “Check due” — here and on the presets overview.
The quality target itself is not set but tested: on September 13, 2026 it was held against the eye on the test corpus. It passes narrowly — what exactly that means, and where the method reaches its limits, is on How we measure quality.
Why these values?
Here the choice of format is a measurement, not an opinion. Several candidates are built for your image — WebP, JPEG and, for graphics, PNG as well. Each is measured against the same frozen reference, and only a candidate that holds your quality target can win.
One rule favors JPEG: WebP only wins with a lead of at least eight percent. Without this hysteresis the output would switch formats between two similar images, and you would end up with a mixed folder in which files differ for no visible reason. Eight percent is small enough to let a real advantage through and large enough to keep noise out.
The third candidate is your own file. It competes unchanged and is measured like all the others. If no re-encode is at least two percent smaller, you get it back. With JPEGs that are already heavily compressed this is not a rare outcome but the right one — the alternative would be a second lossy encode that costs detail and saves almost no bytes.
Which format comes out is therefore not fixed in advance and not promised. It is shown afterwards with the result, together with the chosen quality setting and the measured value.
Frequently asked questions
- Why do I sometimes get a JPEG back instead of a WebP?
Because the JPEG won in this case. Either it was smaller at the same measured quality, or WebP’s lead was below eight percent and not enough for a format change.
If even your original file comes back unchanged, it held its ground against both re-encodes. The result then gives the reason “Your image is already optimal”.
- Does my image lose quality when converted?
A JPEG is already lossy; every re-encode builds on what is left of it. That is exactly why this tool measures instead of estimating: the value shown compares the result with your source as it is.
Only a candidate that holds your quality target is returned — or, if none manages that, the best one measured, with an explicit note.
- Is EXIF data kept?
No. All delivered presets remove metadata, and that includes camera data and GPS coordinates. When the source itself is returned, this happens at container level, without touching the pixels.
In that case the tool does not say “unchanged” but names the removed metadata — a file from which EXIF and GPS have just been taken out is no longer the same file.
- What does the quality value under the result mean?
It is called SSIM. It compares the result with your source — not byte by byte, but by structure: brightness, contrast and local pattern in small windows across the whole image. 1.000 means the images are identical — that is the value you see when the tool hands your own image back. Below that the distance grows.
The value is measured on every run and shown, including when it comes out badly. How the measurement works, and where it reaches its limits, is on the page about our method.
- Is my image uploaded anywhere?
No. Everything runs in your browser: decoding, measuring and encoding happen on your device, in a background thread. There is no server that receives your image, and therefore none where it could stay behind.
This is not a setting you can flip. It is how the tool is built — there is no counterpart it could send anything to.