SVG vs PNG: which one, and why

SVG and PNG solve the same problem in fundamentally different ways, and every practical difference between them follows from that one distinction.

PNG stores pixels. A grid of colour values, one per pixel. The file describes exactly what to display and the display shows it.

SVG stores instructions. A text file of shapes, coordinates and styles. The browser reads them and draws the image fresh at whatever size it is asked for.

Scaling: the headline difference

An SVG at 16px and the same SVG at 1600px are the same file, and both are perfectly sharp. The browser redraws the shapes at the requested size every time.

A PNG has a fixed pixel count. Display it smaller and the browser discards information, which is fine. Display it larger and the browser has to invent pixels, which is not, and the result is the soft, slightly smeared look everyone recognises.

This is why responsive design pushes hard toward SVG for interface graphics. One SVG covers every breakpoint and every display density. Doing the same with PNG means exporting at 1x, 2x and often 3x, then writing srcset to serve the right one.

File size, and where the crossover is

The comparison people expect is "SVG is smaller", and that is true only for a specific class of image.

The crossover is about complexity, not subject. SVG file size scales with the number of shapes, so a hand-traced illustration with ten thousand nodes can be far larger than a photo of the same thing. PNG file size scales with pixel dimensions and colour variety, so it stays flat regardless of how complicated the artwork is.

Two practical notes. SVG is text, so it gzips extremely well, often to a third of its size, and any decent server does this automatically. And an unoptimised SVG straight out of a design tool can easily be three times larger than it needs to be, which is the subject of the optimisation guide.

Colour control and theming

This is the difference that changes how you build, and it is underrated next to the scaling argument.

An inline SVG using currentColor inherits the CSS color of its context. Which means hover states, focus states, disabled states, dark mode and brand theming all work with no icon-specific code at all.

.btn        { color: #444; }
.btn:hover  { color: #FF5A36; }   /* icon follows */
[data-theme="dark"] .btn { color: #EEE; }  /* icon follows */

To do the same with PNG you need a separate file per colour, plus logic to swap between them. For a product with light and dark themes and four interaction states, that is eight files per icon. This alone is usually the deciding argument for interface work. See changing icon colour.

Transparency in both formats

Both support it properly, which is worth stating because a lot of older advice implies otherwise. PNG has a full 8-bit alpha channel, meaning 256 levels of transparency per pixel, so soft edges and drop shadows composite cleanly. This is the main reason PNG survived while GIF, with its single transparent colour and consequent jagged edges, did not.

SVG is transparent by default. There is nothing to enable; anywhere a shape is not drawn, the background shows through.

Accessibility and text

Text inside an SVG is real text: selectable, searchable, readable by screen readers, and indexable. Text inside a PNG is pixels, invisible to everything except OCR.

This matters most for diagrams and charts. An SVG chart with proper title and desc elements is genuinely accessible. A PNG chart is an image with, at best, a summary in the alt text.

Two cautions. SVG text depends on the font being available; if the font does not load, the text reflows and may break your layout, which is why exported SVGs often convert text to paths. And converting text to paths eliminates the accessibility advantage, so it is a real trade rather than a free win.

Security: the reason some platforms block SVG

SVG is XML and can contain <script> elements, event handlers and external references. An SVG uploaded by a user and served from your domain is, in effect, executable content on your origin. That is a genuine cross-site scripting vector, and it is why so many platforms refuse SVG uploads.

If your application accepts SVG from users, sanitise it server-side, strip script elements, event handler attributes and external references, or serve it from a separate domain with a restrictive content security policy. SVGs you author or download from a known source are not a concern. This is a user-upload problem, not an SVG problem.

Decision table

Using both

It is not a commitment. Keep the SVG as your source of truth and export PNGs when a destination demands one. That way you always have a clean original to re-export from at any size, which is exactly the position you want to be in when someone asks for the logo at 2000px for a banner.

The ICON OOP tool exports both from the same icon, so you can take an SVG for the site and a 4x PNG for the deck in the same visit. See also SVG to PNG and what is an SVG file.

Frequently asked questions