How to Audit Existing WebP Files Before Re-Encoding

Many teams eventually inherit a folder full of WebP files with unclear history. Some were exported from original photos. Some were converted from already-compressed JPEGs. Some were generated by a CMS. Some may have been resized, sharpened, or stripped of metadata along the way.

Before running another conversion pass, audit what you already have. Re-encoding a WebP file without understanding its source can make quality worse, increase file size, or hide the fact that the real issue is image dimensions.

The warning that "re-encoding can reduce quality" is only the starting point for a team with hundreds of files. A practical audit creates a record that separates source quality, rendered dimensions, page importance, conversion evidence, and the final decision for each asset group.

Identify the Source Chain#

Start by finding the best available source for each important image. The ideal source is the original high-quality asset, not an already-compressed derivative. If the source chain is unknown, treat the existing WebP as a published derivative, not as a clean master.

Record:

• original camera or design export if available
• intermediate JPEG or PNG
• existing WebP file
• CMS-generated sizes
• published URLs
• pages where the file appears

The goal is to avoid compressing a compressed file again when a better source exists.

Use a small inventory sheet before touching files:

path, published_url, page_url, asset_role, current_dimensions, rendered_dimensions,
best_source_available, source_path, current_problem, proposed_action, reviewer

Example row:

/uploads/hero-dashboard.webp, /assets/hero-dashboard.webp, /product/automation/,
product hero, 2200x1400, 720x458 desktop, yes, /design/exports/hero-dashboard.png,
oversized published derivative, regenerate responsive candidates from source, product marketing

This is the audit trail that makes the work defensible instead of a blind batch job.

Check Whether the File Is Already the Right Size#

A WebP file may be fine as a format but wrong as a delivered asset. If the file is 1800 pixels wide and displayed at 360 pixels, re-encoding at a different quality setting is not the first fix. Resize or generate responsive candidates first.

Inspect intrinsic dimensions and rendered dimensions in the browser. A good audit includes both. Do not approve a re-encoding task until you know whether the page is overserving pixels.

Responsive delivery often saves more than another small compression adjustment.

For file-level facts, a conversion trial should use a separate output directory:

npx -y getwebp ./existing-webp -o ./webp-audit-output --recursive --format webp --json

The GetWebP CLI commands reference documents WebP as a supported input, --output for separate generated files, --recursive for nested folders, --format webp, and --json for structured output. The same reference states that original files are never modified or deleted, which is essential when auditing existing published assets.

Look for Re-Encoding Damage#

Lossy re-encoding can compound artifacts. A file that already has blockiness, banding, halos, or muddy texture may not survive another pass. Google's WebP documentation explains that WebP supports both lossy and lossless compression, but that does not mean every existing file is a good input for another lossy export.

Review common problem areas:

• gradients and skies
• skin tones
• product texture
• sharp text in screenshots
• transparent edges
• low-light photos
• fine patterns such as fabric or mesh

If the existing file already shows damage, look for a better source rather than squeezing it again.

Make the rejection notes concrete:

This keeps the audit from becoming a generic quality checklist.

Separate Lossless and Lossy Cases#

Not all WebP files are the same. A lossless WebP used for a transparent graphic should be reviewed differently from a lossy WebP used for a hero photo. Converting both through the same lossy pipeline can create avoidable damage.

Use the asset role to decide:

• product photos may need a lighter lossy setting
• thumbnails may tolerate stronger compression
• screenshots need text clarity
• transparent logos may need lossless output or SVG
• diagrams may be better as SVG or PNG

The audit should classify files before any re-encoding work starts.

For WordPress libraries, also identify whether the WebP is a generated sibling or an uploaded original. GetWebP's WordPress docs describe a sibling-file model where generated variants sit beside the canonical original, and frontend delivery rewrites output when the optimized sibling exists. See WordPress batch conversion, Frontend Delivery, and the WordPress FAQ. That distinction matters because deleting or replacing the wrong file can turn an optimization audit into a media-management problem.

Compare Against the Published Page#

A file that looks acceptable in isolation may fail in the actual layout. It may sit behind overlay text, be cropped tightly on mobile, or appear next to brand colors that make artifacts visible.

Open the page where the file appears. Check desktop and mobile. If the image is a likely LCP element, check whether the browser selects the expected candidate and whether the URL is discovered early enough.

The published context determines whether the current file is good enough.

Use page context to rank the audit:

This is where broad folder-level advice usually fails: it treats all files in a folder as equal, while real sites need risk-based review.

Use Tools for Facts, Humans for Approval#

Tools can list dimensions, byte size, MIME type, and compression results. Visual approval still needs human judgment for important assets. The cwebp tool documentation from Google includes many encoding options in the WebP tools guide, but option choice should be informed by real examples from your site.

Build a small test set before changing a large folder. Include images that represent the hard cases, not only easy savings.

Keep the tool output with the human review. GetWebP's JSON output reference describes newline-delimited JSON and per-file result fields including outputPath, originalSize, newSize, savedRatio, quality, qualityMode, and status.

Example audit note:

File: /assets/customer-logo-strip.webp
Role: trust proof / customer logos
Source chain: PNG source available
Trial output: /webp-audit-output/customer-logo-strip.webp
Saved ratio: -0.07
Visual review: original edge quality better than trial
Decision: keep PNG-derived approved output; do not re-encode existing WebP

The audit should accept "skip" as a successful outcome when conversion would create risk without a clear page benefit.

Decide: Keep, Resize, Replace, or Re-Encode#

Every audited image should end with a decision:

keep: current file is acceptable and properly sized
resize: format is fine, dimensions are too large
replace from source: current derivative is damaged
re-encode: source is good, settings can improve weight
remove: file is unused

This prevents the team from treating re-encoding as the default answer.

Add one more decision for modern sites:

fix delivery: file is acceptable, but the page selects the wrong candidate or stale URL

That decision is common when an image is not the problem. The problem may be srcset, cache, CDN, or a template choosing a larger derivative than the layout needs.

Keep an Audit Trail#

When you do re-encode, record the input, output, settings, and review outcome. If the file later looks wrong, the team can identify whether the issue came from the source, settings, CMS processing, or delivery path.

A useful note might say: "Existing WebP was not re-encoded because the original JPEG source was available. New responsive WebP outputs were generated from the source at 640, 960, and 1280 pixels. Product texture review passed."

A stronger audit record includes:

Audit date: 2026-01-11
Scope: top 40 traffic pages, 312 WebP files discovered
Converted trial set: 24 files
Kept unchanged: 151
Resize from source: 89
Replace from source: 37
Re-encode approved: 12
Fix delivery/template: 18
Remove unused after reference check: 5
Reviewer notes stored with JSON conversion output

That kind of result shows real editorial and technical judgment. It also helps the next maintainer understand why not every file was converted.

Auditing existing WebP files slows the first step but reduces wasted work. It helps teams protect image quality while still finding real opportunities to improve transfer size and delivery.