DEV Community

Sherotree
Sherotree

Posted on Edited on

SVG to PNG in the tab when the design export is vector-only

Design drops an SVG. Slack wants a PNG. The App Store listing wants a PNG. Email clients laugh at SVG. Your CI screenshot fixture wants a PNG. And you're on Linux, so "just Open in Preview → Export" is not a thing.

I hit this weekly. The vector file is correct — scale, colors, viewBox all fine — but the consumer only eats raster. Opening Illustrator (or waiting for design to re-export at 1x/2x/3x) for a one-off PNG is the slow path.

So I keep a tab workflow: SVG in → PNG out, without uploading the mark to a random converter.

When SVG alone isn't enough

SVG is great inside the product:

  • Icons that follow currentColor
  • Responsive logos that stay crisp
  • Inline chrome that never blur on retina

PNG still wins outside the product:

  • Chat / docs — Slack, Notion, Linear comments often strip or refuse SVG
  • Marketing surfaces — many email clients, some CMS uploaders, OG image pipelines
  • Stores & listings — App Store / Play / directory forms that hard-require PNG/JPG
  • Diff fixtures — visual regression baselines are almost always raster
  • Partner handoff — "send me the logo" usually means a transparent PNG, not XML

Keeping the source as SVG and deriving PNG at the moment of need beats maintaining a parallel PNG folder that drifts.

What goes wrong with the naive paths

Ask design for another export — fine for a brand refresh; painful for "I need a 512px transparent mark before standup."

Desktop converters — ImageMagick / Inkscape / Affinity work, until you're on a locked laptop, a hotel Wi‑Fi machine, or someone else's Chromebook.

Upload-to-convert sites — easiest to regret. Brand SVGs are IP. I don't want the mark sitting in someone else's temp bucket because I needed a PNG for a README.

Screenshot the SVG in the browser — you get wrong DPI, wrong background, wrong crop, and a JPEG-looking mess more often than you admit.

What I actually need from the convert step

For frontend / DX use, the checklist is boring and specific:

  1. Transparent background by default (don't bake white unless I ask)
  2. Explicit pixel size — 128 / 256 / 512 / 1024, not "whatever the viewBox felt like"
  3. No upload — file stays in the tab (DevTools Offline litmus still applies)
  4. Predictable naming — logo-512.png, not download (17).png
  5. Sanity preview before download — catch missing fonts / clipped paths early

If the tool can't do those five, I'm back to Inkscape CLI.

A tab that fits the handoff

When design already gave me the SVG and I just need raster for a non-SVG surface, I've used Uwarp's SVG → PNG tool — drop the file, pick a size, download PNG in the browser. Worth trying when the alternative is another desktop install or an upload converter you can't audit.

For a recurring pipeline (favicon set, store assets, email header), script it: rsvg-convert, inkscape --export-type=png, or a tiny Puppeteer render. The tab is for the one-offs that shouldn't block a PR.

Keep the SVG as source of truth

A few rules that stopped me from growing a junk drawer of PNGs:

  • Commit SVG in the design-system / brand repo; generate PNG at publish time
  • Name by intent + size (mark-on-dark-512.png), never final_final2.png
  • Don't "edit" the PNG — if color changes, change the SVG and re-export
  • Document the sizes you actually ship (email 600w, OG 1200×630, store 1024) so people stop inventing new ones in Slack

SVG → PNG is a packaging step, not a design decision. Treat it like that and the folder stays boring.

Tiny habit

Next time someone asks for "the logo as PNG" and you already have the SVG, don't reopen the design tool and don't upload the brand mark. Convert in a local-ish tab (or a one-liner CLI), verify transparency and size, send the file, close the loop.

Fewer blocked handoffs. Fewer mystery PNGs in Downloads. Same vector source — just the raster shape the other surface actually accepts.

Top comments (0)