PNG to WebP: What Designers Should Check Before Export

Atualmente, este artigo está disponível apenas em inglês.

PNG is the safe export button in many design workflows. It keeps transparency, preserves crisp UI edges, and opens almost everywhere. That safety is why PNG folders quietly become huge: product badges, app screenshots, landing page art, and transparent cutouts all get exported as PNG even when the web page would be faster with a smaller file.

WebP can replace many PNGs, but designers should not treat the conversion as a blind format swap. The right question is: what kind of PNG is this, and what visual promise does it need to keep?

"Smaller file, same transparency" is incomplete guidance for a design workflow. The review record should include the asset role, the export setting, the converted output path, the background used for review, and the reason an asset stayed PNG or SVG.

Sort PNGs by Visual Role#

Before exporting or converting, group the assets by role:

transparent product cutouts
logos and marks
UI screenshots
icons
diagrams
decorative illustrations
flat-color banners
exported design comps

These groups need different decisions. A photographic product cutout with alpha often works well as WebP. A simple logo may belong in SVG. A screenshot with tiny text may need a conservative quality setting. A design comp may not belong on the public site at all.

This sorting step keeps the workflow from turning into “WebP is smaller, so use it everywhere.”

Check Transparency Against Real Backgrounds#

Transparency is the first risk area. WebP supports alpha, but compression settings and edge colors can still create visible halos when the image sits on a dark, tinted, or photographic background.

Do not review transparent images on the checkerboard alone. Place the output on the same backgrounds where it appears in production:

white content sections
dark headers
tinted cards
gradient areas
product gallery backgrounds

Zoom into hairlines, shadows, rounded corners, and semi-transparent glows. If the edge looks dirty, try a less aggressive setting, lossless WebP, or keep the source PNG for that asset.

When you are using GetWebP CLI, do not describe a high --quality value as lossless. The CLI conversion workflow exposes WebP output, auto-quality behavior, and fixed --quality values. If a logo, icon, or UI screenshot needs exact edges and the tested output fails review, keep PNG or SVG for that asset rather than pretending a high number is the same as a lossless requirement.

Treat Logos and Icons Separately#

If the PNG started life as a vector logo or icon, ask why it is raster at all. SVG is often better for marks, UI icons, and simple diagrams because it scales cleanly and can be edited without re-exporting pixels. MDN’s image format guide describes SVG as ideal for interface elements and diagrams that need accurate rendering at different sizes.

Use WebP for raster imagery. Keep SVG for real vector artwork. Keep PNG when a platform requires it or when the file is tiny and the conversion adds complexity without meaningful benefit.

Review Screenshots for Text Sharpness#

Screenshots are risky because compression artifacts show up around text, borders, and flat interface colors. A WebP screenshot can be much smaller, but if labels become soft, the article or documentation feels less trustworthy.

Review screenshots at the size readers will see them. Then inspect:

navigation labels
code text
form fields
thin borders
icons
drop shadows
gradients

For documentation screenshots, it is reasonable to use a higher quality setting than you use for natural photos.

Use a Small Export Test#

Pick a realistic sample from the design file and convert it locally:

mkdir -p ./reports

getwebp ./png-export-sample \
  --recursive \
  --output ./webp-review \
  --quality 84 \
  --json > ./reports/png-webp-q84.ndjson

Compare each output against the original. Write down which groups passed, which need a higher setting, and which should stay PNG or SVG. That note becomes a reusable export rule for the team.

Summarize the report before visual approval:

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

The report is useful when a designer and developer disagree about whether the conversion is worth it: it separates byte savings from the visual decision. The GetWebP CLI command reference documents --recursive, --output, --quality, and --json; the JSON output guide explains the per-file fields.

Keep a short review note:

Asset: product-badge.png
Output: webp-review/product-badge.webp
Role: transparent badge on dark card
Result: rejected, edge halo visible
Decision: keep PNG or redraw as SVG
Reviewer: brand designer

Do Not Delete Source Assets#

The PNG or design-source file is still valuable. WebP is usually a delivery format, not the editing source. Keep the original Figma frame, SVG, or full-resolution PNG where the team expects to find it. Publish the WebP as an optimized derivative.

This distinction matters during redesigns. If the only remaining file is a compressed delivery image, future edits become harder and quality slowly degrades.

Export Checklist#

Before replacing PNG with WebP, confirm:

the asset is raster, not better served as SVG
transparency was checked on real backgrounds
text and UI edges remain clear
brand colors still look acceptable
tiny files are not being optimized for no practical gain
originals remain available
the page using the image was reviewed after the swap

Good design export workflows are not about chasing the smallest possible file. They are about delivering images that load quickly while still respecting the visual job each asset was created to do.