JPG to WebP: When It's Worth It, and How to Convert Without Losing Quality

"Should I convert all the JPGs on my site to WebP?" is the most common — and most commonly botched — item on performance checklists. WebP typically saves 25-35% over same-quality JPG, but before converting everything, three decision questions need answers: how much browser-support gap is left, how much of your JPG inventory is photos versus graphics, and what quality parameter to use. This post covers the criteria and the practical paths; if you just want to convert, the JPG to WebP tool does it locally in your browser — images never upload.

Three decision questions first

1. Does your audience still use old Safari?

Full WebP browser support landed in October 2020 (Safari 14); CanIUse puts 2026 coverage above 97%. The remaining gaps: iOS older than 14 devices, a sliver of legacy browser engines, some old mail clients. The decision rule is simple: if iOS below 14 plus IE is under 1% of your traffic, convert freely; otherwise use <picture> dual-source fallback:

<picture>
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg" alt="...">
</picture>

2. Photos or graphics?

Lossy WebP pays off most on photographic content (continuous tones, natural noise): 25-35% smaller with no visible loss. On sharp graphics (screenshots, icons, text), lossy WebP develops ringing artifacts at lower quality — PNG or lossless WebP is the better fit. Quick reference:

3. Which quality setting?

In the canvas encoding path quality is a 0-1 float (0.75-0.85 is the photo sweet spot). Don't rely on defaults — engines differ, results aren't comparable. Convert one image at q70/q80/q90 and pick the lowest setting you can't distinguish visually; for a batch decision, run a fixed image set and compare output sizes.

Practice: in-browser local conversion

For a single file or a handful, skip the command line — open the JPG to WebP tool:

1. Drop in .jpg/.jpeg files (batch supported);
2. Adjust the quality slider (default 0.8, the photo sweet spot);
3. Download the .webp.

Everything runs on your machine — decoding, canvas re-encoding, and packaging all happen inside the browser process; the image content never leaves it. The reverse direction (someone sends you WebP but a system only accepts JPG) is WebP to JPG; PNG sources go through PNG to WebP; HEIC (iPhone originals) should first go through HEIC to JPG before entering WebP. Pair with the image compressor to finish "convert format + cap width + control size" in one pass.

Command-line batch (site migrations)

For hundreds of legacy images, cwebp in a loop:

# All JPGs in a directory → WebP at q80, originals kept
for f in *.jpg; do cwebp -q 80 "$f" -o "${f%.jpg}.webp"; done

In CI, sharp (Node) or vips (the CLI's engine) handle width-tiered output for responsive srcsets. After any batch run, spot-check 3-5 images zoomed in — a single quality parameter can fail on outliers (a high-contrast text screenshot mixed into photos).

Common traps

• EXIF orientation lost or scrambled: some pipelines output sideways WebP because the decoder ignored EXIF orientation. This site's converter passes imageOrientation: 'from-image' at decode time — the rotation is baked into pixels before re-encoding, so the output never depends on the viewer understanding EXIF;
• Size goes UP: an already-small JPG (under 10KB) or a maximally compressed one may come out equal or larger after WebP. Compare output sizes; under 10% savings isn't worth switching formats (you pay double cache storage);
• PWA/offline packages: some older Service Worker cache implementations mishandle the WebP MIME — test offline flows for real;
• Lossy chains stack: JPG→WebP→recompression accumulates damage each pass. Migrate once, keep the originals archived.

Implementer's note

The site's seven format converters (jpg/png/webp/heic/svg interconversion) share one engine component — each tool is a configuration instance of "target MIME + extension". That keeps EXIF orientation handling, batch logic, and error messaging consistent across all seven: fix once, fixed everywhere. The engine decodes via createImageBitmap with explicit imageOrientation: 'from-image' (respects EXIF, prevents sideways output), falling back to an <img> element path for engines that lack it. Encoding goes through canvas.toBlob, where quality only applies to lossy targets — for PNG the code passes undefined explicitly, because the spec allows a supplied quality to nudge even lossy-capable encoders. HEIC decoding depends on heic2any's wasm (~1.5MB), dynamically imported — only users who actually open a HEIC conversion page download it; the other six converters never pay for it.

FAQ

How much smaller is WebP than JPG, really?

Typically 25-35% at matched subjective quality; q80 WebP vs q80 JPG lands around 30% for photos. Small images (under 10KB) may not shrink — test before batching.

Does converting to WebP affect SEO?

The format itself doesn't rank; the loading speed it buys does — Core Web Vitals (especially LCP) improvements are positive signals. With <picture> fallback, the img alt carries over as-is.

Does the Apple ecosystem still need special handling?

Not in 2026: Safari 14+ (Oct 2020) supports WebP fully, and iOS Photos opens it natively. Only products maintaining legacy-device matrices need dual sources.

Lossless WebP or PNG?

Lossless WebP is 20-25% smaller than PNG with the same compatibility profile. If <picture> fallback is already wired, unify graphics on lossless WebP; without fallback, keep PNG for peace of mind.

These decision notes come from building the image conversion matrix at ToolVault; the EXIF orientation and dual-engine fallback tradeoffs were tested during development.

Field note

Collapsing seven converters into one engine was a maintenance decision: the first few converters each had their own copy, and when the EXIF orientation fix shipped, one was missed — a user reported sideways images. After unification, that class of fix propagates everywhere by construction. The "configure instances from one engine" pattern has since spread to other component families on the site.