"Use SVG for icons, PNG for photos" is true and incomplete. The real decision is about rendering context — and SVG inline, SVG as an image, and SVG in email are three different beasts.
Ask which format to use for an icon and you'll hear "SVG, obviously — it's vector, it scales." That's right often enough to be dangerous, because it hides the decision that actually matters. It helps to remember what SVG really is:
"Scalable Vector Graphics (SVG) is an XML-based vector graphics format for defining two-dimensional graphics, having support for interactivity and animation."
— Wikipedia, "Scalable Vector Graphics" (CC BY-SA 4.0)
It's markup, not pixels — which is the source of both its powers and its traps. SVG isn't one thing you either use or don't; it behaves differently depending on how you embed it, and there are real contexts where PNG is the correct, non-negotiable answer. Get the framing right and the format falls out of it.
When SVG wins cleanly
SVG is the right call when the icon needs to do more than sit still. One file renders crisply at any size, so a single SVG covers every display density without exporting @2x and @3x variants. It can be animated with CSS. It can change colour based on state by setting fill, which is why icon systems love it. And because it's markup, you can target parts of it by ID. For interface icons and logos rendered in a browser, SVG's advantages are real and stack up fast.
When PNG is the right call
Two contexts flip the answer. The first is email: SVG support across email clients is broken and inconsistent — several major clients won't render it at all — so anything bound for an inbox should be a PNG. This isn't a preference; it's the difference between an image and a blank space in a meaningful share of your recipients' inboxes. The second is complex illustration: a detailed graphic with many gradients and thousands of paths can produce an SVG larger than the equivalent PNG, because every one of those paths is text in the file. When the artwork is photographic or highly detailed, raster wins on size. Vector is for the geometric and the simple, not the ornate.
The three embedding contexts
This is the part the "just use SVG" advice skips, and it's where things quietly break. SVG behaves differently in each of three contexts:
- Inline (
<svg>in the HTML): full CSS and JavaScript access. You can style and animate every part. Costs a little page weight and isn't cached separately. - As an image (
<img src="icon.svg">): cached like any image, but the page's CSS cannot reach inside it. Try to recolour it with CSSfilland nothing happens. - As a CSS background (
background-image: url(icon.svg)): no JavaScript, no external references resolve, no per-element styling.
Pick the wrong context and the thing you were trying to do — recolour on hover, animate a path — silently doesn't work, with no error to explain why. The format was fine; the embedding was wrong.
Your exported SVG is bloated
An SVG straight out of a design tool is typically several times larger than it needs to be. Editors leave behind excessive path precision (coordinates to ten decimal places), editor metadata, empty groups, and redundant default attributes — none of which affect how the icon looks. An optimiser strips all of it automatically, routinely cutting file size by a third to more than half with zero visible change. Shipping raw exported SVGs is leaving easy performance on the table.
Accessibility differences
SVG has a meaningful accessibility advantage that rarely gets mentioned in the "SVG vs PNG" conversation: it supports title and desc elements, and screen readers can expose them as the accessible name and description of the graphic. An inline SVG icon with a <title> tag tells a screen reader what the icon means; a PNG in an <img> tag relies on the alt attribute, which many developers leave empty or set to the filename. For decorative icons that convey no meaning, both formats should be hidden from assistive technology — aria-hidden="true" for inline SVG, empty alt="" for PNG. But for functional icons (a search magnifying glass, a close button), inline SVG gives you richer, more discoverable labelling built into the markup itself.
Dark mode and theming
The ability to restyle SVG with CSS is the reason it dominates icon systems on themed sites. An inline SVG icon whose fill is set to currentColor automatically inherits the text colour of its container — so when the page switches from light to dark mode, the icon switches with it. A PNG icon is a fixed set of pixels: a black icon on a white background becomes invisible on a dark background. You end up maintaining two PNG versions (one per theme) or wrapping them in CSS filters that approximate the colour shift. Neither is clean. If a site has a dark mode — and most do now — SVG icons styled with currentColor are a significant maintenance advantage over raster alternatives.
File size is not always what you expect
The assumption that "SVG is always smaller than PNG" breaks down in specific, predictable ways. A simple geometric icon — a hamburger menu, a chevron, a circle — is a few hundred bytes as SVG and often larger as PNG. But an icon with many fine details, complex strokes, or embedded text can produce an SVG that's several times the size of an equivalent PNG, because every path coordinate is text in the file. The crossover point depends on detail complexity: more paths mean more markup, and at some threshold the raster wins on weight alone. Run both through their respective optimisers (SVGO for SVG, a PNG crusher for PNG) and compare the output sizes before deciding. The right format for a specific icon isn't always the one the general rule predicts.
Decide by context, then optimise
Work the decision in order. Establish the rendering context first — browser interface, email, or complex illustration — because that, not "vector vs raster," is what determines the format. If SVG is right, run it through an SVG optimizer before it ships; the size drop is free. If the context demands PNG — email, or artwork too detailed for vector — convert with an image converter, and set the exact pixel dimensions you need with an image resizer so you're not shipping a 512px icon into a 32px slot. The backwards version of this decision starts with the file type. The right version starts with where the image has to render.
← All articles