PSD to PNG: when you ship RGBA, spell out alpha edges, color profile intent, and what “merge visible” really means
PNG fits icons, cutouts, and stickers that need clean alpha: unlike JPEG it avoids blocky damage on soft edges, but full-color masters can get large, and semi-transparent pixels still look different depending on viewer compositing rules. Server-side PSD to PNG is effectively “rasterize the visible composite, then encode”—it does not preserve live type or vectors, so the PSD stays the master and PNG is the handoff. Write down whether you need full alpha, whether targets are sRGB, and whether the art sits on dark UI; otherwise design, web, and prepress will argue over the same file with three backgrounds. Standardize QA as light mat + dark mat + the real CSS background, and log hashes so debates return to evidence instead of screenshots.
How to use PSD to PNG online: upload the signed-off file, wait for visible-layer merge, download, then validate transparent edges on both light and dark mats before versioning the asset
- Freeze the external visibility state in Photoshop: hide annotations and scratch layers, ensure no white plate blocks areas that must stay transparent, confirm artboard size and @2x/@3x targets in the brief, upload, and read the tool’s merge-visible note so nobody expects layered semantics from a PNG.
- Download and inspect the alpha channel, then composite the PNG over white, a brand-dark surface, and the live page background—zoom into hair, shadows, and thin strokes for gray fringes, color halos, or jaggies; if it fails, fix mattes/clipping in the PSD and re-run rather than retouching the PNG blindly.
- Ship with a versioned filename, record color space, ICC embed policy, long edge, and approver; if a CDN serves it, fingerprint URLs so “I replaced the asset” does not collide with month-long caches.
PSD to PNG FAQ (alpha, merge-visible, and file size)
Edges look gray on black backgrounds but fine on white—is the conversion broken, or alpha premultiplication and viewing context?
Semi-transparent anti-aliased pixels interact with the background color; if one side assumes straight alpha and the other premultiplied, you get the classic “dark mat gray fringe.” Validate on the real web or engine background, document the compositing assumption, and adjust mattes or export options in Photoshop—asking for “another PNG export” without changing the math rarely fixes it.
Photoshop “Export As” and the online merge output differ slightly—what should we check before blaming the service?
Diffs often come from visibility stacks, clipping groups, adjustment scope, or stale smart objects—not the PNG encoder. Merge visible to a scratch layer locally and compare ROIs; if local merge already disagrees with Export As, fix the PSD instead of escalating the pipeline.
Hero PNGs are huge and CDN bills hurt—should we ban PNG sitewide, or when is PNG still the right trade?
Keep PNG where you need smooth alpha or crisp cutouts; attack size by limiting long edge, quantizing to palette when art approves, splitting photo backgrounds to JPEG/WebP/AVIF, and documenting which regions truly require alpha. A blanket ban creates more hacks than it saves bytes.
Small type and hairlines look sharp in the big PNG but fuzzy after the browser scales—should we fix the PSD or the CSS?
Align to the pixel grid for the shipped size, avoid odd dimensions and half-pixel nudges, and agree on `image-rendering` plus integer scaling paths—verify at 1x and 2x. Thickening strokes only in the PNG without fixing layout scaling usually trades one artifact for another.
Clients say the PNG “has no layers” and cannot edit copy—how do we set expectations before handoff?
PNG is a raster handoff, not an editable layout; if editing was promised, ship PSD (or the agreed source) alongside and label files RASTER_FINAL versus EDITABLE_MASTER. Clarify in writing that online PSD-to-PNG is flattening, not “export project sources.”