PNG WebP in the tab before you commit another fat raster

#frontend #webdev #performance #dx

Design drops a crisp UI PNG into Slack. Someone drags it into /public. The PR adds 1.4 MB of lossless chrome for a decorative hero that never needed alpha on every pixel. Lighthouse sighs. The tab still looks fine on ethernet.

I’m not anti-PNG. I’m anti-committing a delivery format that wasn’t chosen on purpose. For a lot of web UI stills — screenshots, marketing frames, opaque illustrations — WebP is the boring default once you’ve checked transparency and quality. The conversion should not require a desktop suite or an upload-to-mystery-converter hop when you’re mid-PR.

When PNG should stay PNG

Keep the PNG (or SVG) when:

You need a lossless master for future edits
The asset is a tiny icon where WebP savings are noise
Your pipeline already emits AVIF/WebP at CDN time and /public holds sources only
You’re unsure about alpha edges and haven’t previewed on light and dark UI

Serve WebP (or let the CDN negotiate). Archive PNG as the master when you’ll reopen it in a design tool.

What usually goes wrong

Commit the export as-is — design tools love huge PNGs; git is not a CDN.

JPEG everything — kills alpha; muddy edges on UI chrome.

Upload-to-convert sites — awkward when the raster is an unreleased product screen.

CLI only — fine in CI; heavy when you just need one asset before standup and you’re not near your usual shell profile.

Skip the preview — thin logo strokes and flat brand colors show compression first. A quality slider without a look is guesswork.

A practical conversion checklist

Confirm whether alpha matters in the final placement
Convert with a quality control you can see (try a mid-high setting first; raise it for thin text/logos)
Preview soft edges on both light and dark backgrounds
Keep the PNG master in design/brand storage; commit the WebP you actually serve (or both if the repo owns masters)
Reference the WebP from the page / markdown / CMS — don’t leave the fat PNG linked “for now”

If your build already runs sharp / imagemin / a CDN image API, prefer that for recurring traffic. The tab path is for the one-off that would otherwise land as a raw PNG in git.

Doing it in the browser

When the file is local and you want a quality slider + preview without uploading the asset to a random host, a browser converter is enough. Uwarp’s PNG → WebP tool runs in the tab: drop a PNG, adjust quality, preview, download WebP, with transparency preserved for UI-style sources. Useful for the PR-blocking one-off; script the pipeline when every release needs a batch.

Caveats worth respecting: browser canvas export is not a substitute for tuning a production image CDN, very large sources may hit in-browser dimension/size limits, and you should still eyeball logos at the quality you pick. Keep masters.

HTML that doesn’t leave the PNG linked “for now”

A minimal swap when you only need one format:

<img
  src="/images/pricing-hero.webp"
  width="1200"
  height="630"
  alt="Pricing page with three plan cards"
/>

If you must keep a PNG fallback for older clients, use <picture> with WebP first — but don’t keep linking the multi‑MB master as the img src. Width/height attributes reserve layout; they do not shrink the file on disk.

Wire-up habits that prevent regressions

Prefer <img> / <source type="image/webp"> patterns your stack already uses — don’t invent a second image strategy in the same PR
Name by intent (hero-pricing.webp), not export-final-v7.webp
Document in the README whether /public holds masters, derivatives, or both
Fail CI on newly added PNGs over a size budget if fat rasters keep sneaking in

Tiny habit

Before you commit another multi‑hundred‑KB UI PNG “just for now,” ask whether the page needs PNG semantics or just pixels. If it’s delivery, convert with a preview, keep the master elsewhere, and ship the smaller WebP. Fewer heavy diffs. Fewer accidental uploads of unreleased screens to disposable converters.

DEV Community