When Not to Use WebP: Practical Exceptions

WebP is a strong format for modern web delivery, but it is not the correct answer for every image. Some assets are better left as PNG, JPEG, SVG, TIFF, PDF, or a source design format. Other files can be converted to WebP, but only after testing fallbacks, visual quality, and the publishing workflow.

The point of image optimization is not to make every file end in .webp. The point is to deliver the right image with acceptable quality, reasonable bytes, and a workflow the team can maintain.

A list of scary exceptions does not help a team make a publishing decision. A useful exception test asks whether the output became larger, whether visual quality failed, whether the destination rejects the format, and whether the source should never have been rasterized.

When Compatibility Is the Main Requirement#

Current mainstream browsers support WebP, and for ordinary public websites that is often enough. Compatibility still deserves review when the image will appear outside a normal modern browser context.

Slow down before using WebP if the asset will be used in:

• older enterprise systems
• embedded browsers
• kiosk software
• internal dashboards on locked-down machines
• email templates
• marketplace uploads
• partner portals
• CMS plugins with unclear format handling

The safest approach is to test the real destination. If the platform rejects WebP, rewrites it poorly, or strips it during upload, use JPEG or PNG for that channel. If the asset is on a website and fallback support matters, use responsive markup or a picture element rather than assuming every consumer will behave like a current desktop browser.

MDN's image file type guide is a useful reference when deciding which formats are broadly appropriate for web use.

When the File Is a Source Master#

WebP is usually a delivery format, not a source master. If the image will be edited repeatedly, keep the original in the format that preserves the editing workflow.

Examples:

• PSD or layered design files for creative work
• RAW files for photography
• TIFF or high-quality exports for print workflows
• PNG screenshots that need exact comparison
• original JPEGs from a client or camera

Export WebP after editing, not before. Repeatedly editing and re-exporting from lossy WebP can compound quality loss, and even lossless WebP may remove workflow information that a design or photography tool needs.

A clean workflow keeps originals in one place and writes optimized derivatives into another. That makes it clear which files are editable masters and which files are web outputs.

When the Asset Is Vector Artwork#

If the image is a true vector logo, icon, diagram, or illustration, SVG is often a better web format than WebP. SVG can scale without pixelation, remain small for simple shapes, and stay editable as vector data.

Do not convert vector artwork to WebP just because the rest of the image pipeline uses WebP. Rasterizing a vector logo can make it less flexible and sometimes larger. It can also create edge softness at sizes where the SVG would remain sharp.

Use WebP for raster images. Use SVG when the source is vector and the site can safely render it.

For GetWebP CLI specifically, SVG is not a raster input to feed into the converter. Keep SVG artwork in the vector workflow, or export a deliberate raster fallback when a platform requires one.

When the File Is Already Tiny#

A conversion can be technically successful and still not worth doing. If an image is already 2 KB or 3 KB, a WebP version may save almost nothing. In some cases, it may even be larger because container overhead and encoding choices outweigh the tiny amount of image data.

This commonly happens with:

• small icons
• simple badges
• transparent UI assets
• tiny decorative images
• already optimized thumbnails

For these files, the maintenance cost may be higher than the performance benefit. It is acceptable to leave them alone and focus on larger images that affect real page weight.

When Visual Quality Fails#

Do not keep a WebP output only because the file is smaller. If the image looks worse in a way users will notice, it is not a good replacement.

Common failures include:

• blurry small text in screenshots
• banding in gradients
• rough edges around transparent logos
• smeared texture in product photos
• color shifts after conversion
• animation artifacts

Review images in context. A logo should be checked on the real background colors. A screenshot should be checked at the size where readers need to read labels. A product photo should be checked on the product page, not only in a file preview.

Google's WebP compression documentation is helpful background because it explains the difference between lossy and lossless WebP. The practical takeaway is that choosing the right mode matters.

When the question is "should this asset stay out of WebP?", keep a small test report:

mkdir -p ./reports

getwebp ./exception-sample \
  --recursive \
  --output ./exception-webp \
  --quality 88 \
  --json > ./reports/exception-webp.ndjson

Then list the candidates that need manual review:

jq -r '
  select(.type == "convert.completed")
  | .data.results[]
  | select((.savedRatio // 0) < 0 or .status != "success")
  | [.status, .file, .outputPath, .originalSize, .newSize, .savedRatio, (.error // "")]
  | @tsv
' ./reports/exception-webp.ndjson

A negative savedRatio means the WebP output is larger than the input. That is not automatically a failure if the page still benefits from a format rule, but it is a strong reason to leave a tiny asset, already optimized thumbnail, screenshot, or transparent graphic alone. The GetWebP CLI command reference documents the flags, and the JSON output guide explains the report fields.

When Print or Publishing Workflows Need Other Formats#

Print production and high-end publishing have requirements that web delivery does not. A print shop may expect PDF, TIFF, specific color profiles, or high-resolution JPEG exports. A WebP file that works well on a website may be rejected or inappropriate for print.

Use WebP for web derivatives. Keep print masters in the format required by the printer, publication system, or brand workflow.

This distinction matters for teams that reuse the same product photos across web, packaging, and print. The web folder can contain optimized WebP outputs while the asset library keeps print-ready originals.

When the Delivery System Cannot Be Tested#

Sometimes the issue is not the image. It is the delivery system.

Avoid a broad WebP migration if you cannot test:

• CDN caching behavior
• CMS image size generation
• responsive image markup
• fallback handling
• social preview images
• RSS readers or email previews
• rollback behavior

A WebP file may be correct, but the page may still serve the wrong candidate, cache an older derivative, or break a downstream preview. Test a small group of representative pages before converting a whole site.

When AVIF or JPEG Is a Better Fit#

WebP is often a practical default, but AVIF or JPEG may be better in specific cases. AVIF can be worth testing for large, high-impact images when the workflow supports fallbacks and encoding time is acceptable. JPEG may remain the better choice when external compatibility is more important than file size.

Format decisions should be based on the asset and the channel. A product hero image on your own site, an image uploaded to a marketplace, and a print catalog source should not all be forced through the same output rule.

A Practical Decision Table#

The Short Version#

Do not use WebP when compatibility, editing, print, vector artwork, tiny file size, or visual quality makes another format better. Use it when it improves web delivery without damaging the workflow around the image.

That is the healthier rule: WebP is a web delivery tool, not the answer for every image format. The best optimization keeps the files that improve the site and leaves clear exceptions where another format is the better engineering choice.