SVG vs PNG: When Each Wins, With Sizes and a Security Test

Use SVG for anything drawn from shapes: logos, icons, simple charts and diagrams. It stays sharp at every size, and is usually tiny. Use PNG for anything built from pixels, or where the file has to work outside a browser: screenshots, images with complex textures, and uploads to systems that do not accept SVG. And be careful accepting SVG from other people, because an SVG file can contain code.

The core difference

A PNG is a grid of coloured pixels, a raster image. It has a fixed resolution. Enlarge it, and the software has to guess at the missing pixels, so it goes soft or blocky.

An SVG is a text file describing shapes, in XML. Here is the complete file for the logo we tested below, a blue circle with a white tick:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 64 64">
  <circle cx="32" cy="32" r="28" fill="#1f4f8f"/>
  <path d="M18 34l10 10 18-22" fill="none" stroke="#fff"
        stroke-width="6" stroke-linecap="round" stroke-linejoin="round"/>
</svg>

There are no pixels in there. The browser draws those instructions fresh at whatever size is needed, so a high-density phone gets the same crisp edges as a billboard would. It also means you can edit it in a text editor, change its colours with CSS, or animate parts of it.

How the sizes compare

We rendered that logo in Chromium at several sizes and compared them with the SVG, which is 233 bytes (182 gzipped).

The PNG grows with its dimensions, and the SVG does not grow at all. So to serve this logo sharply on 1x, 2x and 3x screens you would need three PNGs, or one SVG.

The advantage is not universal, though. SVG size depends on how complicated the drawing is, not on how large it is displayed. To show this, we made a scatter chart of 20,000 dots at 800 by 600:

Here, the uncompressed SVG is more than twice the size of the PNG. And that is before the browser has to create 20,000 elements, which costs memory and makes the page slower to work with. For very dense charts, maps and traced photographs, raster wins. Gzip on the server helps with download, but not with the drawing cost. An auto-traced logo from a raster source can also come out with thousands of needless points, so clean it up in a vector editor.

When each one wins

For more on choosing between raster formats, see JPG vs PNG vs WebP.

SVG problems that catch people out

Fonts. Text in an SVG uses whatever font the viewer has, unless embedded. A logo with live text can render in the wrong typeface on another machine. Convert text to outlines in your vector editor before exporting a logo.

Missing size. An SVG with only a viewBox and no width or height may collapse to an unexpected size, in some contexts. Set dimensions in your HTML or CSS, and add width and height attributes to the <img> tag so the layout does not shift.

External references. An SVG may point to fonts or images on other servers. Displayed through <img>, those references will not load, so parts of the drawing can go missing.

Editor clutter. Design tools add metadata, hidden layers and long decimal numbers. A tool such as SVGO can often cut an exported SVG’s size substantially with no visible change.

Security: an SVG can contain code

This is the difference most comparisons leave out. PNG is pure image data. SVG is a document format, with support for <script> elements and event handlers such as onclick. If it runs in your site’s context, a script can read a logged-in user’s page, act on their behalf, and steal data. That is cross-site scripting.

Whether the code runs depends on how the SVG is loaded. We tested this. We served an SVG containing a script that makes a network request, then embedded it four ways in Chromium and watched the server’s log:

So <img> is safe from scripts, and CSS background images are treated similarly. The danger is in the other three, and the last one is easy to overlook. If your site lets users upload an SVG, and serves it from your main domain, then anyone who follows a direct link to that file runs its script on your domain, with your users’ cookies in scope. An attacker only needs to send them the link.

If you accept SVG uploads, in order of preference:

1. Do not accept them. Allow PNG, JPG and WebP. For many sites, this is entirely reasonable, and our SVG to PNG tool lets users convert before uploading.
2. Convert to a raster on the server and keep only that output. A PNG cannot carry scripts.
3. Sanitise with a maintained library, such as DOMPurify and its SVG profile. Do not write your own regular expressions for this. XML has many ways of disguising the same thing, and past bypasses of home-grown filters are common.
4. Serve from a separate domain that holds no logins, and add Content-Disposition: attachment and a restrictive Content-Security-Policy header, so a direct visit does not run anything in a sensitive context.

Only ever display them through <img>, and never inline them.

As for SVGs you download yourself: an icon from an unknown site pasted inline into your code has the same access as your own scripts. Open it in a text editor first, and search for <script, on attributes such as onload, and <foreignObject>. Icon libraries from known projects are fine.

Converting between them

SVG to PNG is a clean operation. You choose the output size, and nothing is lost relative to that size. Export at the largest size you need, and do so from the original vector each time. Our SVG to PNG tool does this in your browser, so it is also an easy way to check what your SVG looks like when rendered by a browser.

PNG to SVG is not a true conversion. “Tracing” software guesses at shapes from the pixels. It can work on a clean, high-contrast logo, and it gives poor results on photos and gradients, often with a file that is larger than the PNG. If you have lost a logo’s original vector file, redrawing it is usually better than tracing it. Some converters only wrap the PNG inside an SVG file as embedded Base64 data, which gives you the worst of both: a raster image that scales no better, with a larger file.