JPG to WebP: Cut Photo File Size for Faster Web Pages

Your product gallery or blog post looks great and loads like treacle. PageSpeed Insights says the same thing every time: "Serve images in next-gen formats." Translation: your JPGs are bigger than they need to be, and the browser is downloading megabytes it could have skipped.

Converting JPG to WebP is the single highest-leverage fix on a photo-heavy page. Done right, you cut 25–35% off each file with no visible difference. Done carelessly, you ship washed-out colours, strip the orientation data and break images in email clients. This guide covers the conversion step itself — the settings, the metadata flags, the batch commands and the fallback plan.

WebP vs JPG size: what you actually save

The honest comparison isn't "WebP q75 vs JPG q75" — those aren't the same picture. Quality scales differ between encoders, and WebP's lossy mode holds detail better at lower numbers. The practical matched pair most people land on is WebP quality 75 against JPG quality 85: visually indistinguishable at 100% zoom on a typical photo, meaningfully smaller on disk.

A typical result on a 2000px-wide product shot: hero-shot.jpg at 420 KB becomes hero-shot.webp at around 270 KB. Across a 12-image gallery that's roughly 1.8 MB saved before you touch anything else on the page. Savings vary by content — smooth skies and studio backgrounds compress hardest, dense texture like foliage or fabric weave saves least.

Two things worth knowing before you convert the whole library:

• Re-encoding is lossy on top of lossy. Your JPG already threw away data; WebP throws away a little more. Going from a quality-85 JPG to quality-75 WebP is fine. Going from a quality-60 JPG to quality-50 WebP stacks artefacts.
• Convert from the best source you have. If the original TIFF, PNG or camera export still exists, convert from that instead of the web JPG. One lossy step beats two.
• Resize first, then convert. Serving a 4000px image into a 800px slot wastes far more bytes than any format choice. Fix the dimensions, then compress.

Convert JPG to WebP in the browser

If you have a handful of images, or you're on a machine where you can't install tools, the quickest route is a browser converter. Drop the files into the JPG to WebP converter, pick your quality level, and download the results — no account, no install, no command line.

This is the right choice when you're converting a blog post's worth of images, testing whether WebP is worth it before committing, or handing the task to someone non-technical on the team. For other formats — PNG, HEIC, AVIF and the rest — the image converter hub covers the same workflow.

Keep the original JPGs. You'll want them for the fallback, and for the day you decide to re-encode at a different quality.

The command line: cwebp and ImageMagick

For hundreds of files or a build step, use cwebp — the reference encoder from Google's libwebp. Single file:

cwebp -q 75 -metadata icc hero-shot.jpg -o hero-shot.webp

That -metadata icc flag matters more than people expect. By default cwebp strips all metadata, including the colour profile. Images shot or edited in Adobe RGB or Display P3 then saved without their ICC profile get interpreted as sRGB by the browser — reds go flat, saturated blues shift. Carrying the profile through keeps the colour you approved.

Metadata options in short:

• -metadata icc — colour profile only. The sensible default for web images: correct colour, no GPS coordinates or camera serial numbers riding along.
• -metadata none — strip everything. Smallest files, but risks colour shifts on wide-gamut sources.
• -metadata all — keeps EXIF, ICC and XMP. Use for archives or photography portfolios where capture data is part of the point.

One EXIF gotcha: if your JPGs rely on the EXIF orientation tag to display the right way up, stripping metadata will rotate them sideways. Bake the rotation in first with magick input.jpg -auto-orient output.jpg, then convert.

Batch JPG to WebP across a whole folder

macOS and Linux, converting every JPG in a directory:

for f in *.jpg; do cwebp -q 75 -metadata icc "$f" -o "${f%.jpg}.webp"; done

ImageMagick does the same job in one line and handles resizing at the same time:

magick mogrify -format webp -quality 75 -resize 1600x\> -auto-orient *.jpg

The 1600x\> means shrink anything wider than 1600px, leave smaller images alone — no upscaling. mogrify writes new .webp files beside the originals rather than overwriting them, so your JPGs survive.

Spot-check the results before you deploy. Open the biggest file and the one with the most fine detail at 100% and compare against the JPG. If you see blocking in gradients or mushy texture, bump to -q 80 and re-run; the extra bytes are worth it.

Fallbacks: email and old Safari

Every current browser handles WebP. The gaps are elsewhere:

• Safari before version 14 (and the iOS versions that shipped with it) can't decode WebP. Small share now, but on an older-skewing audience it's a broken image, not a slow one.
• Email clients are far behind browsers. Several major desktop and webmail clients still don't render WebP reliably. Never put WebP in a marketing email — use JPG there, full stop.
• Older social scrapers and feed readers may not generate previews from WebP. Keep og:image pointing at a JPG.

On the web, the fix is the <picture> element. The browser picks the first source it understands and ignores the rest — no JavaScript, no user-agent sniffing:

<picture>
  <source srcset="hero-shot.webp" type="image/webp">
  <img src="hero-shot.jpg" alt="Walnut desk lamp on a linen background"
       width="1600" height="1067" loading="lazy">
</picture>

This is why you keep the originals. The JPG isn't dead weight — it's your safety net for the 2% of requests that need it, and for every email and share card you ever send.

A 20-minute rollout plan

If you want results on your worst page today:

1. Run PageSpeed Insights and note the three largest images it flags.
2. Resize those to the maximum width they're actually displayed at.
3. Convert at quality 75 with -metadata icc, or drop them into the online converter.
4. Compare file sizes and eyeball the results at 100%. Expect roughly 25–35% off.
5. Wrap each in <picture> with the JPG as <img> fallback.
6. Re-run PageSpeed and confirm the next-gen format warning has cleared, then batch the rest of the library.

One pass through a gallery usually removes more weight than a week of script tuning — and unlike most performance work, it's reversible and easy to verify by eye.

FAQ

Can I convert JPG to WebP without losing quality?

Not literally — lossy WebP re-encodes the pixels. But at quality 75 the difference from a quality-85 JPG is invisible in normal viewing. If you need pixel-exact output, cwebp -lossless exists, though lossless WebP on a photo usually produces a larger file than the JPG. Reserve it for graphics and screenshots.

Does Google penalise or reward WebP?

There's no ranking bonus for the format itself. The benefit is indirect: smaller images improve Largest Contentful Paint, and Core Web Vitals are a ranking signal. The format is a means, not the goal.

Should I use AVIF instead?

AVIF compresses better again, but encodes more slowly and has thinner support in older tooling. A common setup serves AVIF first, WebP second and JPG last in the same <picture> block. If you're adding one format today, WebP is the lower-friction win.

Will converting strip my copyright and GPS data?

By default cwebp strips everything. Use -metadata all to keep EXIF and XMP including copyright fields, or -metadata icc to keep colour accuracy while deliberately dropping location data — usually what you want for public web images.

Does WebP support transparency?

Yes, both lossy and lossless WebP support an alpha channel — which is why it also replaces PNG well for logos and UI graphics with soft edges.