JPG to WebP: A Practical Migration Workflow

Este artigo atualmente só está disponível em inglês.

JPEG is still everywhere because it is familiar, compatible, and good enough for many photos. The problem is that “good enough” often turns into years of oversized uploads. A site can end up serving multi-megabyte JPEGs for blog headers, product galleries, team pages, and landing pages long after those images should have been resized and converted for web delivery.

WebP is a practical upgrade for many JPEG-heavy sites, but a safe migration is not just a find-and-replace job. You need to know which JPEGs are used, how they are displayed, what quality is acceptable, and how to roll back if a page does not look right.

"Convert JPG to WebP for smaller files" skips the evidence a migration needs. The migration record should include the page inventory, preserved JPEG originals, a representative sample converted with repeatable commands, and a report of successes, failures, skipped files, and visual review decisions.

Inventory the JPEGs That Matter#

Start with pages, not folders. A folder scan tells you what files exist; a page inventory tells you what users actually download.

For each important page, record the JPEGs that load in the browser. Note the file size, natural dimensions, displayed dimensions, and role on the page. A 90 KB inline image and a 3 MB hero should not receive the same priority.

Prioritize:

largest above-the-fold images
repeated thumbnails on listing pages
product or portfolio images
evergreen blog headers
images loaded on mobile

This makes the first migration pass useful even if you do not finish the entire library at once.

Resize Before You Convert#

Many JPEG libraries are too large in two ways: dimensions and bytes. If the source is 4000 by 3000 pixels and the page displays it at 900 pixels wide, format conversion alone is not the full fix.

Create a target width for each image role. For example, a blog hero may need a larger source than a card thumbnail. A product zoom image may need more detail than a team headshot. Resize to the role, then convert to WebP.

The result is easier to review because you are not mixing two questions: “Is WebP good enough?” and “Why is this image still enormous?”

Convert a Representative Sample#

Choose a sample that includes easy and difficult images:

bright outdoor photos
dark indoor photos
faces
product texture
gradients
images with text overlays
thumbnails

Run a local conversion into a separate output folder:

mkdir -p ./reports

getwebp ./jpg-sample \
  --recursive \
  --output ./webp-sample \
  --dry-run

getwebp ./jpg-sample \
  --recursive \
  --output ./webp-sample \
  --quality 82 \
  --json \
  --manifest ./reports/jpg-webp-manifest.json \
  > ./reports/jpg-webp.ndjson

Keep originals untouched. Converted WebP files should be treated as delivery assets, not the only remaining copy.

Summarize the conversion report before any references change:

jq -r '
  select(.type == "convert.completed")
  | .data.results[]
  | [.status, .file, .outputPath, .originalSize, .newSize, .savedRatio, .quality, .qualityMode, (.error // "")]
  | @tsv
' ./reports/jpg-webp.ndjson

Also check whether the run was truncated or failed:

jq -r 'select(.type=="convert.truncated" or .type=="convert.failed") | .data' ./reports/jpg-webp.ndjson

The GetWebP CLI command reference documents --recursive, --output, --quality, --json, and --manifest; the JSON output guide explains outputPath, savedRatio, quality, and qualityMode.

If you convert a nested JPEG library into one shared output directory, check for duplicate basenames first. A getwebp ./jpg-sample --output ./webp-sample run writes by basename in the output directory, so team/hero.jpg and blog/hero.jpeg both want hero.webp unless you split the runs or rename the source variants.

Review Quality in Context#

Open the actual page or a staging copy. Compare the original JPEG and WebP output where users will see it. Then inspect the risky details: faces, product edges, fabric texture, shadows, skies, gradients, and text overlays.

Do not approve solely by compression percentage. A smaller hero image that makes the brand look careless is not a successful migration. At the same time, do not reject a good output because it looks slightly different at unrealistic zoom.

The practical standard is: does the image still do its job on the page?

Update References Carefully#

There are three common rollout patterns:

Replace references in templates with WebP URLs and keep JPEG backups.
Use <picture> so WebP is served first and JPEG remains the fallback.
Let a CMS, plugin, or CDN rewrite delivery while originals remain in the media library.

For a hand-maintained site, <picture> is often the clearest fallback. For a CMS, check how it handles generated sizes and responsive image markup. WordPress, for example, can output srcset candidates, so review the full candidate set rather than only the main src.

Watch for Common Migration Mistakes#

The biggest mistakes are predictable:

converting unused folders before high-traffic pages
re-encoding already optimized images
deleting JPEG originals too soon
ignoring mobile layouts
updating src but not srcset
forgetting cache and CDN behavior
using one quality setting for every image role

Each mistake is avoidable if the migration has a staging pass and a review checklist.

Final Checklist#

Before you call the migration complete, confirm that important pages load the WebP files, fallbacks work where needed, source JPEGs are recoverable, visual review passed, and cache behavior is understood. Google’s WebP documentation and MDN’s image format guide both support WebP as a strong web image format, but your site still needs its own review.

The best JPEG to WebP migration is controlled, reversible, and boring. That is what makes it safe.