Most PNG-to-WebP problems I hear about aren't conversion problems — they're handoff problems. A designer exports a beautiful PNG, a developer drops it on the site, and the 3 MB "hero-final-v2-ACTUAL.png" tanks the page. The fix isn't a better compressor; it's a delivery checklist both sides follow.
I'm the developer of FileOnTap, and I wrote this after watching the same three mistakes ship on project after project.
1. Deliver at 2x, but name the 1x intent
Export your source PNG at double the display width (a 1200 px hero needs a 2400 px source if it's ever zoomed or shown on retina), but tell the developer the intended display size. The developer picks the actual output width; the designer just guarantees the source is sharp enough. A source that's exactly 1x is a dead end — nobody can upscale it later without blur.
2. Flatten what doesn't need transparency
Transparency doubles as a file-size trap. Before exporting, ask: does this image actually need an alpha channel? Photographs, gradients, and full-bleed heroes almost never do. Flatten those to opaque. Reserve transparency for logos, icons, and overlays that genuinely sit on varying backgrounds.
3. Ship WebP alongside the PNG source — every time
Make WebP part of the standard deliverable, not an afterthought the developer does (or forgets) at deploy time. The workflow is short enough to be painless: convert PNG to WebP online in the browser, keep the PNG as the lossless source, deliver both files with matching names (hero-1200.png + hero-1200.webp). If the designer's pipeline produces both, the "we'll optimize later" step that never happens simply disappears.
Use a browser-local converter for this — client work, unreleased product screenshots, and embargoed campaign assets shouldn't be uploaded to a third-party server just to change a file format. Converting locally keeps the assets on your machine end to end.
4. Document the decisions in the handoff
A one-line note per image beats a Slack thread later. For each asset, record: intended display width, whether transparency is required, and the source file location. That's it. Three fields. Future-you — or the next designer on the project — will know exactly why pricing-table-800.webp exists and what to regenerate if the layout changes.
5. The QA pass developers should run
When the assets land, the developer's five-minute check: (1) every <img> has explicit width/height or an aspect-ratio box (prevents layout shift regardless of format); (2) text inside converted screenshots is still legible at 100%; (3) transparent assets actually render correctly on the page background; (4) file sizes are sane — if a WebP is barely smaller than its PNG, the source was probably a photograph that should have been evaluated differently.
The takeaway
WebP conversion takes seconds. The expensive part is always the rework when assets arrive wrong. A checklist that fits in a handoff doc — 2x sources, flattened-by-default, WebP shipped alongside PNG, three fields of documentation, a five-minute QA — removes an entire category of launch-week firefighting.
And when you need the conversion itself done privately, compress PNG without uploading: the files never leave your browser.
Top comments (0)