Convert JPG images to WebP for 25 to 35 percent smaller files with no visible quality loss. Batch conversion runs in your browser — nothing is uploaded.
Drop one JPG or fifty onto the upload zone, set the quality slider, press Convert All, and download the WebP files. Every image is decoded and re-encoded by your own browser using the HTML canvas toBlob() API with the MIME type image/webp. Nothing is uploaded. There is no server round trip, no queue, no account, and no watermark — if you disconnect your network after the page loads, the converter still works.
The tool accepts JPG only. It checks each dropped file's MIME type for jpeg and its filename for .jpg or .jpeg, and silently skips anything else, along with any file over 50 MB. If you dragged in a PNG or a HEIC and nothing appeared in the list, that is why. For other input formats, the site's Image Format Converter handles a wider set.
If you arrived here trying to go the other way — you have a WebP that some program refuses to open and you need a JPG — this page is the wrong direction. Use the WebP to JPG converter instead.
.jpg/.jpeg extension swapped for .webp.Two honest limitations worth knowing before you start. Download All triggers one download per file, not a ZIP — on a batch of thirty images your browser will ask whether the site may download multiple files, and you have to allow it. And the converter does not resize, crop, rotate or strip metadata as separate options; it re-encodes at the image's natural pixel dimensions.
The slider maps directly to the quality argument of canvas.toBlob(), so 80 on the slider is 0.80 passed to the browser's WebP encoder. This is lossy WebP. There is no lossless toggle. That matters for the choice: quality 100 in lossy WebP is not the same thing as lossless — it is the encoder trying very hard, and it usually produces a file bigger than the JPG you started with.
| Slider value | Reasonable use | What to expect |
|---|---|---|
| 90–100 | Hero images, product photography where detail is the product | Files often near or above the source JPG size. Rarely worth it. |
| 80–85 | The default zone. Photographs in articles, blog headers, galleries | Meaningful savings, no artefacts most viewers will spot. |
| 70–80 | Thumbnails, list images, anything rendered small | Good savings. Soft edges appear on fine text or hard lines. |
| 50–70 | Placeholders, background textures, low-priority imagery | Visible smearing in flat gradients — skies, skin, out-of-focus areas. |
| 10–50 | Deliberate degradation, blur-up placeholders | Obvious blocking and colour banding. |
The practical method is to convert one representative image at 80, look at it full size, and only move the slider if you have a reason. Then re-run the batch. Because conversion is instant and local, iterating is cheap — there is no upload to sit through.
JPEG dates from the early 1990s and encodes 8×8 blocks with a discrete cosine transform, quantising the coefficients. Lossy WebP borrows its intra-frame coding from the VP8 video codec: variable block sizes, better prediction of each block from its already-decoded neighbours, and arithmetic (boolean) entropy coding rather than JPEG's Huffman tables. Better prediction means less residual to store, and better entropy coding means the residual that remains costs fewer bits.
Two consequences worth internalising. First, the savings depend heavily on the image. Smooth, gradient-heavy photographs compress far better in WebP than grainy, high-detail ones. Second, the savings depend on the source JPG's own quality. A JPG that was already saved at quality 60 has had its detail thrown away once; re-encoding it to WebP at 80 asks the encoder to faithfully reproduce JPEG's artefacts, which is expensive. The best results come from converting the highest-quality JPG you have, not one that has already been squeezed.
WebP is decoded by current versions of Chrome, Edge, Firefox, Safari and the mobile browsers built on those engines — Safari added support in version 14, which shipped with macOS Big Sur and iOS 14. For a site serving current browsers, plain <img src="photo.webp"> is fine.
Where support is still worth thinking about is everything that is not a browser. Email clients, older desktop image viewers, some CMS upload validators, print pipelines, digital signage players, and plenty of desktop software written before 2020 will reject a .webp file or show a broken icon. That is the real support question in practice, and it is why the "when to keep the JPG" list below is longer than you might expect.
If you want belt and braces on a website, the <picture> element lets you offer both and let the browser pick:
<picture><source srcset="photo.webp" type="image/webp"><img src="photo.jpg" alt="…"></picture>
Keep the JPG on disk if you do this. Converting is one-way in the sense that matters: you cannot recover the JPG's original detail from the WebP, only re-encode the already-lossy result.
.webp attachment may get nothing useful. Send JPG.+ percentage, the conversion has cost you both size and a generation of quality. Keep the JPG.| What you see | Cause | Fix |
|---|---|---|
| Dropped file never appears in the list | Not a JPG, or over the 50 MB limit. Both are skipped silently. | Check the extension. PNG, GIF, HEIC and TIFF need a different converter. |
| "Failed to load image" | The browser could not decode the file — truncated download, renamed file that is not really a JPEG, or a corrupt scan. | Open it in an image viewer first. If that fails too, the source file is damaged. |
| "Conversion failed" or "Canvas not supported" | The encoder returned no blob. On very large images this is usually a canvas size or memory limit. | Downscale the image first, or convert fewer files at once. |
| Output larger than the input (orange percentage) | Quality set too high, or the source JPG was already heavily compressed. | Lower the slider to 75–80 and re-convert, or keep the JPG. |
| Browser blocks the batch download | Download All fires one download per file. | Allow multiple downloads for the site, or download rows individually. |
| Tab becomes unresponsive on a huge batch | Decoding and encoding happen on the page's main thread, one file at a time. | Work in batches of ten to twenty; large files take a moment each. |
No. The conversion path is entirely local: the file is turned into a blob URL with URL.createObjectURL(), decoded by an Image element, drawn to an off-screen <canvas>, and re-encoded by canvas.toBlob(). There is no fetch, no form post, and no upload endpoint anywhere in that chain. The preview thumbnails and the download links are blob URLs pointing at memory in your own tab, and they are revoked when you remove a file or clear the list.
That is the reason this approach is worth preferring for anything you would not casually email — client photography under contract, medical or legal exhibits, internal screenshots, images with location metadata. It is also why the tool has no file-size accounting or history: there is nothing on our side to account for.
Say you have a folder of eighteen photographs for an article, each roughly 2–4 MB straight out of a phone. Drop the whole folder's contents on the zone. Convert one first at quality 80, download it, and view it at the size it will actually appear on the page — not zoomed to 400%, which is a test no lossy format passes. If it holds up, press Convert All and read the percentages down the list. Any row that shrank by a large margin is a photograph with lots of smooth area; a row that barely moved is probably fine-grained or was already compressed hard. Then Download All, allow the multi-file prompt, and you have eighteen .webp files with the original names.
If two or three rows come back orange, remove them, drop the originals back in, drop the slider to 70, and convert just those. Keeping the JPG for those specific images is a perfectly reasonable answer too — a mixed page of WebP and JPG is not a problem for any browser.