JPG to WebP Converter
Turn JPG and JPEG photos into WebP without uploading them anywhere — the conversion runs on your own machine.
JPEG has no transparency, so transparent areas are filled with this color.
Everything runs locally in your browser. Nothing is uploaded to any server — close the tab and your files are gone.
How to convert JPG to WebP
Drop your JPGs in
.jpg and .jpeg both work, one file or an entire shoot. WebP is already selected as the output format here, so there is nothing to configure before you start.
Leave the quality near 75
That is where the slider starts and where photos usually want to be. Read the next section before dragging it much lower — a JPEG has already been compressed once, and the second pass does not behave like the first.
Resize while you are here
Photos straight out of a camera are far larger than any web layout needs. Fitting the longest edge to 2048 px before the encoder runs saves more bytes than any quality tweak, and it happens as part of the same pass rather than as a second save.
Check one, then take the batch
Open the compare slider on the shot you care most about — a portrait with skin tones, or anything with a large area of sky. If it holds up at your setting, the rest will too. Download them individually or all at once as a ZIP.
Re-encoding a photo that was already compressed
This is a second lossy pass
A JPEG is not the original photograph; it is what survived the camera or the export dialog. Converting it to WebP discards detail a second time, from a picture that had already lost some. The two passes do not cancel out — they stack. That effect is what people mean by generation loss. Choosing the right container once, rather than converting twice, is the way out of that; our format comparison sets out what each one costs.
Quality 75 here is not quality 75 in your export dialog
The number is a dial on a particular encoder, not a shared measurement. WebP at 75 and JPEG at 75 are different codecs making different decisions, so a photo exported from a design tool at 60 can survive WebP at 75 comfortably, and another exported at 90 may still show something. Judge the result in the compare view rather than by matching numbers across programs.
So do not go far below the default
Dropping to 40 or 50 on a file that came out of a JPEG exporter tends to look worse than the same setting applied to an untouched original, because the encoder is now also spending bits reproducing the previous pass’s artifacts. If the result looks soft or blocky, raise the slider instead of accepting it.
What travels across and what does not
The photo is decoded to raw pixels and encoded fresh, so nothing that lived outside the pixels comes with it: no EXIF block, no shutter or lens data, no caption or copyright field. The pixels themselves pass through an 8-bit-per-channel sRGB buffer, which also means an embedded colour profile is not carried into the WebP. If the JPGs are Adobe RGB or ProPhoto masters, convert them to sRGB in your editor first, otherwise the colours will look flat once a browser treats them as sRGB.
Keep the JPG you started from
Every round trip costs something and nothing puts it back, so treat the WebP as a delivery copy and keep the JPG as the master — especially if you may need to re-export at a different size later. Going back to the JPG each time is always better than converting a file that has already been converted.
What a large batch actually does to your machine
Files queue up and run across up to three background workers on a desktop, one on a phone or a device with less than 4 GB of memory. Each row prints how long its own file took, so a slow batch is visibly your hardware rather than a queue somewhere else — and closing the tab stops it, because there is no job running anywhere but here.
JPG to WebP — frequently asked questions
Is a .jpeg file treated differently from a .jpg?
No. They are the same format with two spellings of the extension, and both are read by the same JPEG decoder here.
Does converting a JPEG to WebP lose quality?
A little — it is a lossy format written from an already-lossy source. At the default quality of 75 the difference is very hard to spot on a photograph while the file gets meaningfully smaller. What is worth avoiding is moving the same picture back and forth between lossy formats repeatedly.
Why did my WebP come out larger than the JPG?
Usually because the JPG was already saved at a low quality and you converted it at a high one. The row marks that case with a “+x% larger” label so you can see it immediately. Lower the slider toward 75, or simply keep the original.
Is the EXIF data kept?
No. The photo is decoded to raw pixels and re-encoded, so no EXIF block is written into the WebP. If a camera record, caption or copyright field matters, keep the original JPG alongside the converted file.
My photos are in Adobe RGB — will the colours shift?
They can. Everything here moves through an 8-bit sRGB pixel buffer and no ICC profile is written into the output, so a wide-gamut JPG loses the tag that told software how to read it and tends to come out looking duller. Convert to sRGB in your photo editor before the batch and the WebP will match what you saw.
Can I convert hundreds of photos at once?
Yes — no file cap, no watermark, no account. They queue up and run across the worker pool, so a big batch is bounded by your own hardware rather than by an upload allowance.
Should I pick AVIF instead of WebP for photos?
AVIF usually lands smaller at a similar quality, and it is in the format picker — note that it opens at a default quality of 50 rather than 75, because the two scales are not comparable. The trade is time: AVIF encoding is far slower here, and one large photo can take a minute. For a batch you need to get through, WebP is the practical default.
Does the tool re-compress a JPG that is already small enough?
It converts whatever you give it — there is no threshold that skips a file. If a photo is already lean, the row will simply show a small saving or a size increase, and the honest move at that point is to keep the JPG.