SVG vs PNG: Which Format Should Your Website Use?

Most articles answering "SVG vs PNG" pick a winner. That framing is wrong. The two formats solve different problems, a normal site needs both, and the decision that actually matters is narrower: which of my files should be which?

Here is the version you can apply in ten minutes.

The difference in one paragraph

A PNG stores a grid of colored pixels at one fixed resolution. Scale it up and the software invents pixels that were never there — the blur you see on a stretched logo is not a rendering bug, it is the format doing what it was designed to do.

An SVG stores instructions: draw a path from here to here, fill it with this color. The browser re-renders those instructions at whatever size the layout asks for.

Everything below follows from that one fact — file size, sharpness on high-density screens, editability, and how much work it takes to ship a dark-mode version of your logo.

Where PNG still wins

PNG is the right format more often than SVG evangelists admit.

• Anything photographic. A photograph has millions of distinct colors and no clean edges to describe as paths. A vector version of a photo is either a huge file or a stylized imitation, not your photo.
• Screenshots. Text, UI chrome, and anti-aliasing all behave like noise to a tracer.
• Gradients, glows, and soft shadows. Traced gradients come out as visible bands; traced shadows come out as a pile of translucent shapes.
• Social and OG images. X, LinkedIn, and Facebook do not render SVG when you point og:image at one. This is the single most common mistake in this whole area — a site that looks fine everywhere else shows a blank card when someone shares it.
• Anything going into a platform that doesn't accept it. Marketplaces, ad networks, print shops, and most submission forms still ask for PNG or JPG.

Where SVG wins

• Logos and wordmarks. One file replaces logo.png, logo@2x.png, logo@3x.png, and the dark-mode variants you keep forgetting to export.
• Icons and UI. Small, crisp at any density, and you can change the color with one CSS rule if the SVG is inlined.
• Favicons. Chrome and Firefox accept SVG favicons and they scale cleanly — but Safari still needs a PNG or ICO fallback, so ship both.
• Diagrams, charts, and simple illustrations. A flat, few-color drawing is exactly what paths are good at.
• Anything a designer will re-open. SVG survives Illustrator, Figma, and Inkscape round-trips. A traced PNG usually does not.

The performance trap: SVG is not automatically smaller

This is where most comparisons get it wrong, and where a lot of sites quietly get slower after a "modernization".

An SVG's weight is a function of how many points are in it. A hand-drawn two-color logo can be a couple of kilobytes. The same logo traced from a compressed PNG at a high color count can be many times larger, because the tracer is faithfully describing every wobble in the source pixels. Vector files do compress well over the wire (gzip or brotli), but they do not compress to nothing.

Practical rules:

1. Measure after optimizing, not before. Run the SVG through an optimizer (SVGO is the standard one) to strip editor metadata, empty groups, and redundant precision.
2. Cut the color count in the source. If your logo has three colors, a trace at 16 colors means 13 colors of noise that also multiply the path count.
3. Compare against the PNG you'd have shipped. A well-compressed 40 KB PNG usually beats a 200 KB trace of the same logo.
4. Inline only what needs CSS control. Inline SVG cannot be cached separately; for anything that appears on every page, a cached <img> is cheaper.

Four technical mistakes that cost more than the format choice

The format is a small decision. These mistakes are bigger, and all four are common.

1. An SVG with no width and height. An SVG that only carries a viewBox has no intrinsic size. Without CSS dimensions, it can collapse to nothing or blow up the layout while it loads — which is exactly the layout shift Core Web Vitals penalizes. Set both.

<img src="/logo.svg" width="160" height="40" alt="Acme" />

2. A stripped viewBox. Designers sometimes remove it to "fit the box". You just lost the scaling behaviour the format was chosen for.

3. Inline SVG with no accessible name. A screen reader sees an inline <svg> and nothing else unless you name it:

<svg viewBox="0 0 160 40" role="img" aria-label="Acme">
  <title>Acme</title>
  <path d="..." fill="currentColor" />
</svg>

4. Both social previews and favicons left in SVG only. Ship og:image as a 1200×630 PNG, and give the favicon a raster fallback.

What this has to do with AI search

Answer engines and AI crawlers read text and markup. They do not look at your logo and recognize your brand.

So if a piece of information exists only inside a raster image — the product name in a hero graphic, a pricing table baked into a screenshot, a diagram explaining your architecture — a model summarizing your page will simply miss it. The fix is not a file format; it's making sure the information also exists as text: real headings, descriptive alt attributes, <figcaption> where it belongs, and copy that states the claim instead of illustrating it.

SVG helps at the margin, because an inline SVG with a <title> and readable path structure is at least a machine-parseable asset, and because vector diagrams can carry text as text. But the real rule is the boring one: anything important should exist as words on the page. (If you're also publishing an llms.txt file to point AI crawlers at your best pages, the same logic applies — see our llms.txt guide.)

If your logo only exists as a PNG

This is the common case for a small site, and it is fixable in a few minutes.

First, check whether the file is even traceable. Tracing re-describes what is already in the pixels; it does not add information.

Good candidate: flat colors (two to eight), hard edges, no shadows or gradients, a clean or transparent background, and roughly 800 px or more on the long edge.

Bad candidate: a gradient logo, a photo-based mark, heavy compression artifacts, or a file pulled from a screenshot. If it's a bad candidate, don't convert — rebuild it as a flat two-color mark and trace that.

Second, convert it. Ideally without uploading your unreleased logo to a random server, and without a watermark in the output. Browser-based converters run the trace locally with WebAssembly, so the file never leaves the machine — the PNG to SVG converter here does the trace in your browser, free and without an account, and gives you a color palette to clean up before downloading.

Third, clean up. Set the color count to the number of colors actually in the mark, raise the speckle filter until stray one-pixel dots disappear, then hide or delete the leftover shapes in the palette. Look at the result at 100% zoom, not at thumbnail size — thumbnails hide everything.

Fourth, name it. logo.svg. Not logo-final-final-v2.svg. You will be looking for it on the day you need it most.

The five-second decision rule

If you take one thing from this: SVG is not "the better format", it is the better format for shapes. Logos, icons, and diagrams are shapes. Photographs and screenshots are not — and no amount of conversion tooling will change that, which is also why a traced photo always looks like a filtered photo rather than a drawing.