SVG vs PNG: Which to Use, With Measured File Sizes

SVG vs PNG comes down to what the file stores. An SVG stores drawing instructions that are redrawn sharp at any size; a PNG stores a fixed grid of pixels. Use SVG for logos, icons and anything that is scaled or cut, and PNG when the image is already pixels or the destination only accepts them. Below: a job-by-job table, byte counts from files we rasterised and measured, the cases where the SVG is the bigger file, and why an SVG can still look blurry.

SVG vs PNG: the short answer

A PNG is a grid of pixels with lossless compression and an optional alpha channel. Its sharpness is fixed the moment it is saved: display it larger than its pixel dimensions and the renderer has to invent pixels in between, which reads as blur. An SVG is XML text describing shapes — paths, circles, gradients — in its own coordinate system, and the renderer draws it fresh at whatever size it is shown.

So is SVG better than PNG? For artwork made of shapes, yes: one file serves a 16-pixel favicon and a shop sign, stays editable as text, and is usually smaller once compressed. For photographs, screenshots and anything with continuous tone, no. And where the destination only takes pixels — an email client, a social upload — the answer is a PNG exported from the SVG at the right size. The working rule: keep the SVG as the master, and export PNG copies for the places that need pixels.

What actually differs between the two formats

This is a complete icon, and one of the two files we measured below:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"
     fill="none" stroke="currentColor" stroke-width="2"
     stroke-linecap="round" stroke-linejoin="round">
  <path d="M3 10.5 12 3l9 7.5"/>   <!-- roof -->
  <path d="M5 9v11h14V9"/>         <!-- walls -->
  <path d="M10 20v-6h4v6"/>        <!-- door -->
</svg>

Written on a single line without the comments, as we measured it, that is 244 bytes. There are no pixels in it. The viewBox="0 0 24 24" is a grid to draw on, not a size — the viewBox guide covers how that grid maps onto the page.

SVG vs PNG by job: web, logo, print, Cricut, email and more

Most of the “which is better” argument disappears once you name the job.

Three rows need a source. On email, Can I email records Outlook for Windows 2007–2016 as not displaying SVG images, and Gmail (tested September 2026) displaying them only after converting them to PNG. On social media, specs are published in pixels — LinkedIn’s share-image guidance asks for at least 1200 × 627. On QR codes, if a small PNG must be shown larger, image-rendering: pixelated keeps the modules sharp-edged rather than smeared.

For web UI, the real decision is less SVG vs PNG than how you ship the SVG; the inline SVG vs img guide and SVG icons vs icon fonts cover that. Logos get a fuller treatment in logo file formats.

SVG vs PNG size: what we measured

Most comparisons assert that SVG is smaller without measuring anything, so we measured. Two hand-written files: the house icon above, and a 288 × 64 logo — a circle-and-hills mark with a gradient, plus the word “Northfield” set in Avenir Next Bold and outlined to paths, coordinates at one decimal place, not run through an optimiser. Each was rasterised with sharp 0.35.3 (librsvg 2.62.90) directly at the target size. PNGs were written at zlib level 9 with libpng’s adaptive filtering both off and on, keeping the smaller file; palette PNGs were quantised with libimagequant.

• At 1× it is a draw. The icon SVG and a 24-pixel PNG are 30 bytes apart; the logo SVG and its 1× PNG, 38. Anyone promising that SVG is always far smaller has not measured a small file.
• The SVG wins on count and on the wire. One 244-byte icon replaces a 1×, 2× and 3× PNG set totalling 1,193 bytes. Served with gzip, the icon drops to 186 bytes and the logo to 1,743. PNG is already deflate-compressed and gains nothing: the 1× logo PNG went from 4,220 to 4,243 bytes.
• PNG tracks pixels, SVG tracks drawing. Each PNG grew as its dimensions did; the SVG does not change. In the logo, 3,805 of the 4,258 bytes are the outlined wordmark — lettering is where vector bytes go.
• Palette PNG is not free. It halved the large flat-colour logo exports but made the 24- to 72-pixel icons bigger, because the palette itself costs bytes.

To repeat the logo half of the test on your own files:

// npm install sharp — it renders SVG with librsvg and writes PNG with libpng
import { readFileSync, statSync } from 'node:fs'
import { gzipSync } from 'node:zlib'
import sharp from 'sharp'

const svg = 'logo.svg'
const gz = (file) => gzipSync(readFileSync(file), { level: 9 }).length
console.log(svg, statSync(svg).size, 'bytes, gzipped', gz(svg))

for (const width of [288, 576, 1200, 2400]) {
  const png = `logo-${width}.png`
  // resize() on SVG input re-renders the vector at that width; it does not upscale pixels
  await sharp(svg).resize({ width }).png({ compressionLevel: 9 }).toFile(png)
  console.log(png, statSync(png).size, 'bytes, gzipped', gz(png))
}

When the SVG is the bigger file

Photographs are where the vector argument breaks. We took a 3840 × 2160 landscape photograph, scaled it to 1600 × 900 and saved it several ways:

An SVG that wraps a raster is the raster plus a third: base64 spends four characters on every three bytes, so both wrappers come out about a third larger than the image inside them, with none of the scaling benefit.

Real vectors fare worse. We posterised the photo to 16 colours at 400 × 225 and wrote every horizontal run of one colour as a rectangle, giving an SVG that re-renders identically to the 16-colour PNG (checked value by value). The PNG is 14,297 bytes; the SVG is 276,816 — more than nineteen times larger, and still over four times larger after gzip (62,128 bytes). A real tracer smooths and merges shapes instead, trading detail for bytes. Thousands of paths also cost the browser time on every paint; the optimisation guide covers that side. For photographs, PNG beats SVG, and JPEG or WebP beat both.

Why is my SVG blurry?

A true vector cannot be blurry from scaling. When one looks soft, it is nearly always one of these:

1. It contains a raster. An <image> element can hold a PNG or JPEG, and plenty of “PNG to SVG converters” produce exactly that. The pixels inside scale like any bitmap. SVGs generated in SVG Maker AI have <image> elements removed on the server, so a generated file will not carry one.
2. It was exported to PNG too small. A 24-pixel PNG shown at 48 CSS pixels on a 2× screen is stretched four times across. Export at the largest device size it will be shown at.
3. Something rasterised it for you. Gmail turns SVG images into PNGs, and any tool that converts an SVG to a bitmap on import fixes its resolution at that moment.
4. It is off the pixel grid. A 24-unit icon shown at 20 pixels puts edges between pixels, and a 1-unit stroke centred on a whole-number coordinate straddles two pixels, drawn as two half-strength rows. Show icons at multiples of their grid.

To check for the first cause, search the file:

# How many embedded raster images does the file contain?
grep -o '<image' logo.svg | wc -l

# Which kinds, when they are inlined as data URIs?
grep -o 'data:image/[a-z+]*' logo.svg | sort | uniq -c

SVG vs PNG for printing, and what DPI actually does

DPI (strictly PPI, for a file) is a number stored beside the pixels saying how many of them to fit into an inch. It adds no detail. Print width is pixel width divided by DPI, so our 1200-pixel logo PNG prints 4 inches wide at 300 DPI and 8 inches wide at 150 — same file, same pixels. To make the point we wrote it out twice, tagged 72 and 300 DPI: both files are 21,513 bytes and the decoded pixels have the same SHA-256 hash. In PNG the value lives in an optional chunk, pHYs.

import sharp from 'sharp'

// Same pixels, two different DPI tags.
await sharp('logo-1200.png').withMetadata({ density: 72 }).toFile('logo-72dpi.png')
await sharp('logo-1200.png').withMetadata({ density: 300 }).toFile('logo-300dpi.png')

for (const file of ['logo-72dpi.png', 'logo-300dpi.png']) {
  const { width, height, density } = await sharp(file).metadata()
  console.log(file, `${width}×${height} px`, `${density} DPI`, `${(width / density).toFixed(2)} in wide`)
}

// logo-72dpi.png 1200×267 px 72 DPI 16.67 in wide
// logo-300dpi.png 1200×267 px 300 DPI 4.00 in wide

So for printing, work backwards: inches × target DPI = pixels you need. 300 is the usual target for anything read at arm’s length; large-format work viewed from across a room needs fewer. Better still, send vector. Many print workflows are built around PDF, so if the printer accepts vector files, export a PDF from the SVG in Inkscape — SVG Maker AI exports SVG, PNG, a data URI and a React component, but not PDF or EPS (SVG vs EPS covers the older format). If a DTF or sublimation shop asks for PNG, give them one sized for the print.

SVG vs PNG for Cricut and other cutting machines

A cutting machine follows outlines, so it wants vectors. Cricut’s upload guide splits files the same way: SVG and DXF arrive as finished designs and are separated into layers, while PNG, JPG, GIF and BMP arrive as a single layer. Saved as a cut image, a raster keeps only its outline and loses its colours; saved as Print Then Cut, it is printed and cut around the outside. That gives a simple rule — SVG for vinyl, iron-on and anything cut from material; transparent PNG for stickers and printables.

Before uploading an SVG to cut:

• Make sure shapes are closed, filled paths — an open stroke has no inside to cut.
• Convert strokes to filled outlines (Inkscape: Path → Stroke to Path).
• Run the raster check above; an embedded image will not cut.

The Cricut SVG guide goes further on cut-ready files.

Converting SVG to PNG, and PNG to SVG

SVG to PNG: choose the size at export

Rasterising loses nothing as long as you render at the size you need; it is upscaling afterwards that blurs. The SVG editor exports PNG at 1024 pixels on the long edge, with a transparent background, rendered in your browser — enough for slides, documents and most web use — and refuses markup that will not parse. For anything larger, use Inkscape or sharp:

# Inkscape 1.x: height follows the aspect ratio
inkscape logo.svg --export-type=png --export-width=2400 --export-filename=logo-2400.png

# Node, with sharp installed in the current project
node -e "require('sharp')('logo.svg').resize({ width: 2400 }).toFile('logo-2400.png')"

Or do it in the browser, at any width the canvas allows (MDN notes iOS caps canvases at 4096 × 4096):

// Rasterise SVG markup to a PNG Blob at any pixel width, in the browser.
// Expects a standalone SVG: xmlns on the root and a viewBox.
async function svgToPng(svgText, width) {
  const doc = new DOMParser().parseFromString(svgText, 'image/svg+xml')
  const svg = doc.documentElement
  if (doc.querySelector('parsererror') || svg.localName !== 'svg') {
    throw new Error('Not valid SVG markup')
  }

  // Take the aspect ratio from the viewBox, then write the target size onto
  // the root so the browser draws the vector at that size (no upscaling).
  const [, , vbWidth, vbHeight] = (svg.getAttribute('viewBox') || '').split(/[\s,]+/).map(Number)
  if (!(vbWidth > 0 && vbHeight > 0)) throw new Error('The SVG needs a viewBox')
  const height = Math.round((width * vbHeight) / vbWidth)
  svg.setAttribute('width', width)
  svg.setAttribute('height', height)

  const markup = new XMLSerializer().serializeToString(svg)
  const url = URL.createObjectURL(new Blob([markup], { type: 'image/svg+xml' }))
  try {
    const img = new Image()
    img.src = url
    await img.decode()

    const canvas = document.createElement('canvas')
    canvas.width = width
    canvas.height = height
    canvas.getContext('2d').drawImage(img, 0, 0, width, height)

    return await new Promise((resolve, reject) => {
      canvas.toBlob((blob) => (blob ? resolve(blob) : reject(new Error('Canvas export failed'))), 'image/png')
    })
  } finally {
    URL.revokeObjectURL(url)
  }
}

// Usage: fetch a file, render it 2400 px wide, download the result.
const text = await (await fetch('/logo.svg')).text()
const png = await svgToPng(text, 2400)
const link = document.createElement('a')
link.href = URL.createObjectURL(png)
link.download = 'logo-2400.png'
link.click()

Expect canvas PNGs to be larger: the same 512-pixel icon came out of Chromium’s canvas at 12,482 bytes against 4,172 from sharp, so run a PNG optimiser afterwards if bytes matter.

PNG to SVG: tracing or redrawing

These are different operations. Tracing — potrace, or Inkscape’s Trace Bitmap — follows the edges in your pixels: faithful to the shapes, noise included. The tracing guide explains how it works and when it holds up.

SVG Maker AI’s PNG to SVG converter (sign-in required) does not trace. A vision model describes your image, and a new SVG is generated from that description. You get a fresh vector drawing that resembles the original rather than a copy of it — proportions, lettering and small details can change. That suits turning a rough icon or sketch into clean vector art; for a client’s logo that must match exactly, trace it or redraw it by hand.

Where to go next

To check what an SVG really contains, paste its markup into the SVG editor’s code panel — the status bar shows its file size and whether the XML is valid — and export a PNG from there. To get a vector from a raster, start from the PNG to SVG converter, or the Cricut SVG page if the file is headed for a cutter.

On the format itself, what an SVG file is starts from the beginning, the tracing guide covers edge tracing in depth, and the optimisation guide takes the 4,258 bytes of a logo like ours further down.