Convert JPG to WebP online, free

The saving is per file, but the value is cumulative. A product gallery with twelve photos that each shed 60 KB takes 720 KB off a single page. On a site serving thousands of page views a day, that adds up across a month into real bandwidth, and real loading time, recovered.

The double-lossy trap, and how to stay out of it

Here is the one thing that separates a clean JPG to WebP conversion from a muddy one. Your JPG is already lossy: when it was first saved, the camera or editing app discarded detail to hit its file size. Converting that JPG to lossy WebP runs the photo through a second round of compression. Each round leaves artifacts, the faint blocking and ringing around edges and in flat areas, and the second round can pile new ones on top of the first.

The fix is quality, not magic. When you convert an existing JPG, keep the WebP quality high, around 80, rather than dropping to 60 or 50 to chase a smaller number. At quality 80, the encoder has enough room to reproduce the JPG it was handed, including the JPG's own artifacts, without adding a visible second layer of its own.

Push the slider down to 50 and you start to see the stacking: softer edges, color banding in skies, a smeared look in shadow detail. That degradation does not come back. Once you have re-encoded at low quality, the lost detail is gone.

A practical rule: treat the quality of the original JPG as your ceiling. If a JPG was saved at quality 90, a WebP at quality 80 looks identical and saves space. If the JPG was already a low-quality export, converting it at quality 80 will not repair it, but it will avoid making it worse.

After any batch, click Compare on a file to put the JPG source and WebP output side by side. If the two look the same, the quality setting was right.

Why lossy WebP, not lossless, is the right pick for photos

WebP has two modes: lossy and lossless. The names invite a wrong instinct, that lossless must be the safe, high-quality choice. For photos, it is the wrong one.

Lossless WebP stores every pixel exactly, which is wonderful for flat graphics, logos, and screenshots with large blocks of identical color. A photo has almost no identical neighbouring pixels, so lossless mode has nothing to fold away and the file balloons. A lossless WebP of a photo can be larger than the JPG you started with.

Your source is a JPG, so the photo has already passed through lossy compression once. There is no perfect original left to preserve. Storing those already-imperfect pixels byte for byte spends a lot of file size protecting detail that was discarded at the camera.

Lossy WebP at quality 80 gives you the smaller file the whole conversion is meant to produce, at a quality the eye reads as identical. For JPG photo sources, lossy is not a compromise. It is the correct tool.

The page-speed payoff for sites built on JPG photos

If your site leans on photography, product pages, a portfolio, a recipe blog, a news site, the images are usually the heaviest thing on the page. They are what the browser spends the most time downloading and what a visitor waits to see. Largest Contentful Paint, the Core Web Vitals metric that measures when the biggest visible element finishes loading, is most often a hero image or the first product photo. Shrink that image and LCP improves directly.

Take a product page where the main photo is a 280 KB JPG. Convert it to a 190 KB WebP and you have cut 90 KB off the single element that defines LCP for that page. On a mid-range phone over a typical mobile connection, that is a measurable head start on the moment the page feels ready. Repeat it across a catalogue and the effect shows up in field data, the real loading times Google records from actual visitors, which feed into search ranking signals.

There is a bandwidth side too. Every byte you stop sending is a byte your CDN or host does not bill you for and a byte a visitor on a metered mobile plan does not pay for. A 30 percent cut across an image-heavy site is a 30 percent cut on the largest slice of your egress. For a busy store or a popular blog, that is a line item that shrinks every month after a one-time conversion.

Real jobs: galleries, hero images, and old libraries

The most common reason people land here is a photo library that predates WebP. A store has 400 product JPGs uploaded over three years; a blog has hundreds of inline screenshots and header images. Drop them in batches of up to 100 files, each up to 50 MB, set quality 80, and download the WebP set as a ZIP with file names preserved and only the extension changed. The conversion runs across your browser's worker pool, so a full batch finishes without freezing the tab.

For e-commerce galleries, quality 78 to 82 is the band to stay in. Product photos need to look honest on both standard and retina screens, and that range holds detail in fabric texture and edges while still cutting 30 to 40 percent off the JPG. For a hero or banner image that sets the first impression of a page, you can sit at the top of that band, quality 82 to 85, since it is the single most-seen image and worth a few extra kilobytes. For thumbnails and grid previews that render small, you can drop lower, since the viewer never sees them at full size.

Blog and editorial images sit comfortably at quality 80. Screenshots with text and UI are a partial exception: if a screenshot is mostly sharp graphics rather than photographic content, nudge quality up to 85 to keep text edges crisp. For pure photos, 80 stays smaller and looks the same.

When you should leave the photo as JPG

WebP is the better web format, but it is not the right answer for every destination. If you are handing a photo to a platform or service that rejects WebP, convert nothing. Some older email clients, a few legacy upload forms, and certain partner systems still expect JPG only, and a WebP they cannot read is worse than a slightly larger JPG they can. Check what the destination accepts before you convert in bulk.

Print workflows are another stop sign. Print shops and design tools built around CMYK and high-resolution masters expect JPG or TIFF, not a web format tuned for screen delivery. If a photo is heading to print, keep the JPG, or better, the original master file.

The same holds when you need one universal file you can hand to anyone without asking what they support. JPG is the format that every device, every app, and every person can open, and that universality is sometimes worth more than 30 percent fewer bytes.

If you need JPG output from a WebP you already made, turn WebP back into JPG to reverse the conversion. If you would rather stay in JPG and just make the file smaller, you can compress the JPG first without changing format. And if you are working from a source that is not a JPG photo at all, the general convert-to-WebP tool covers those other starting points.

Serve WebP and keep the JPG as a fallback

Browser support for WebP is wide today, so most sites can serve it directly. If you want a belt-and-braces setup that still covers the rare client without WebP, keep the original JPG alongside the new WebP and let the browser choose with the HTML picture element. The pattern is short: a picture element wraps a WebP source and a fallback img pointing at the JPG. A browser that understands WebP loads the WebP; one that does not falls back to the JPG without any scripting.

Written out, it reads like this: <picture><source srcset="photo.webp" type="image/webp"><img src="photo.jpg" alt="..."></picture>. The img tag inside is what older browsers and screen readers use, so it still needs a real alt attribute. Because you are converting on your own machine here, you finish with both files in hand, the WebP for nearly every visitor and the JPG ready as the safety net, which makes this fallback pattern free to adopt.