JPG to WebP Converter

Convert JPG photos to WebP to cut page weight without a visible drop in quality.

This tool runs entirely in your browser. Your data is never uploaded, never stored, and never leaves your device.

Trades a JPEG for a WebP at a quality you set — the cheapest way to cut the weight of an image-heavy page. How much you save is decided entirely by that quality number, and the tool prints the before-and-after sizes so you can settle it by looking rather than guessing.

How to use it

1Choose the JPG; its pixel dimensions and byte size appear above the controls.
2Set the quality — 90 is the default — then press Convert to WEBP and read the size comparison.
3If the result is still too heavy, drop the quality and convert again, then download.

Example

Input: A 1600 × 1067 JPEG photo, 124.0 KB, at quality 90
Output: A 54.9 KB WebP — 56% smaller. Quality 80 gave 30.2 KB, quality 75 gave 21.9 KB

Two things can make the WebP bigger than the JPEG instead. Quality 100 encodes losslessly, which means faithfully reproducing every compression artefact already in the source: a 113.1 KB photo came back at 728.3 KB that way. Grain is the other one — a noisy 1200 × 800 JPEG converted at 90 came out 9% larger than the original, where the smooth photo above lost more than half its weight. You are re-compressing something already compressed, so start at 90 and step down until the number looks right; never step up to 100. The image is not resized, and one file is converted per run.

What happens to your data

This tool runs entirely in your browser. Your input is never uploaded to a server, never stored, and never logged. Encoding uses your browser's own WebP encoder, so the same source file can come out a few kilobytes different on a different browser. If the browser cannot write WebP, the tool reports that rather than quietly handing back a PNG named .webp.

Last updated August 2026

A performance report is what sends most people here. Lighthouse or PageSpeed Insights points at the photographs on a page as the reason it loads slowly and suggests a modern image format; or a theme's upload limit refuses the file straight out of the camera. The pictures are fine. They weigh too much.

Work out first whether the weight comes from the compression or from the dimensions, because only one of those is settled here. A photograph four thousand pixels wide, shown in a column seven hundred pixels wide, carries detail nobody will ever see, and no codec rescues that — resizing costs it far more weight than re-encoding does. The pixel dimensions are untouched by this conversion, so resize first if the picture is oversized.

The second thing to settle is who receives the file. Every current browser reads WebP, which is why it is the safe format on the web itself. Away from the browser support is patchier — email clients, older design and office software, print services and a good many upload forms still list JPG and PNG and nothing else. If the picture is going into a newsletter, someone else's slide deck or a printer's hands, send the JPEG.

The common mistake is converting an export that was squeezed once already. Lossy passes accumulate, so a JPEG saved at low quality and then re-encoded carries both sets of damage. Start from the best version you still have, and keep it.

How it works

Toolvore reads the JPEG with your browser's own decoder, draws the decoded image onto a canvas exactly as many pixels wide and tall as the original, and asks the browser's WebP encoder to write that canvas out at the quality you set. Everything after the decode is a re-compression of pixels rather than a translation between files, so nothing of the JPEG's own structure crosses over and no detail it discarded when first saved comes back. The canvas is also the limit of what survives: it holds colour values and nothing else, so an EXIF block carrying the camera model, capture date and GPS coordinates, a copyright field and any embedded colour profile are all left behind, and the pixels reach the encoder in the canvas's colour space rather than the photograph's. It is weakest wherever you want precision — no byte target, no resizing, no access to the encoder's own settings, and one file per run, so a particular size is reached by moving the quality and converting again.

Common use cases

Getting product photographs on a slow gallery page down to a sensible weight
Answering a Lighthouse warning about serving images in a modern format
Preparing photographs for a blog whose theme already serves WebP
Squeezing a picture that sits a few kilobytes over an upload limit
Removing camera details and GPS coordinates from a photo, since redrawing leaves the metadata behind
Finding the quality number an automated build step will then apply

Frequently asked questions

Is WebP actually better than JPEG?＋

For photographs, usually yes at the same apparent quality — lossy WebP uses a more modern codec and holds detail together at settings where JPEG has started to show blocking. The advantage is not universal. A thumbnail already down to a few kilobytes has little left to give, and a picture that is mostly flat colour or sharp text is better served by a lossless format than by either. WebP also does things JPEG cannot: it carries an alpha channel and can hold an animation. Judge it on the file in front of you rather than on the format's reputation.

Which programs can open a .webp file?＋

Every current major browser displays WebP, so dragging the file onto a browser tab is the quickest way to look at one, and recent Windows and macOS releases preview it in their built-in viewers. The gaps are elsewhere: older desktop editors, email clients that show a broken image instead, plenty of marketplace and government upload forms, and print services that ask for JPEG or TIFF. If the person receiving the file will open it outside a browser, ask what they accept first, or send the JPEG and keep the WebP for the web.

Does converting a JPEG to WebP lose quality?＋

Yes, at any lossy setting, and the loss lands on top of whatever the JPEG had already given up. Detail thrown away when the photo was first saved is gone before this page sees it, so what you are choosing is how much more to surrender. Check the places that show it: skies and other smooth gradients, skin, dark areas, and hard edges against flat colour. Zoom to full size rather than trusting the small preview. Keep the original JPEG too — repeatedly re-editing and re-saving a lossy file is how a picture quietly degrades.

Is my photo uploaded anywhere when I convert it?＋

No. The decoding, the canvas and the encoding all happen inside the tab, and the finished WebP exists as a blob in your browser's memory until you save it — the download link points at that blob rather than at a server. What does leave the page, where analytics is configured, is an event naming the tool along with the before and after byte counts; the image is no part of it. The newsletter form under the download sends an address only if you type one. Close the tab and both source and result are gone.

Should I use WebP or AVIF?＋

AVIF generally produces smaller files at a similar quality, particularly on photographs, and it handles wide colour and high dynamic range that WebP does not. It costs more to encode, arrived later, and is still likelier to meet software that does not recognise it. WebP is the conservative pick and has the longer record in browsers. Sites that care about both serve AVIF first, WebP after it and JPEG last, letting each browser take the first format it understands. Nothing on this page writes AVIF — the conversion here is JPEG to WebP.

How do I serve WebP without breaking software that cannot read it?＋

Use the picture element and list the sources newest format first: a source pointing at the WebP, then an ordinary img tag pointing at the JPEG. A browser takes the first thing it recognises, and anything that ignores source elements falls back to the img, so nobody sees a broken image. Serve both files rather than deleting the JPEG. On a CMS, a plugin or the host's image pipeline usually arranges this and keeps the original. Check too that your server sends image/webp as the content type, since some older configurations do not.

Can I convert a whole folder of JPEGs at once?＋

Not here — one file goes through per run, chosen, converted and downloaded before the next. For a handful that is fine; for a few hundred it is the wrong shape of tool. A batch belongs in a command line or a build step, where a converter walks a directory, applies one quality setting to every file without anyone clicking, and writes the output beside the originals rather than into a downloads folder. An image CDN or a CMS plugin does the same work at request time. A manual pass is still where you settle the quality number automation will apply.

Does converting strip EXIF data and GPS coordinates?＋

It does, as a consequence of how the conversion works rather than as an option you switch on. The picture is redrawn onto a canvas and re-encoded from those pixels alone, and a canvas carries no metadata, so the camera make and model, the exposure settings, the capture date, the copyright field and any GPS coordinates never reach the WebP. That is welcome when you are publishing a photograph taken at home and would rather not publish where home is. It cuts the other way if you need a credit line preserved, which calls for a converter that copies metadata deliberately.