SVG has a reputation for being the format that is "always sharp". That is true – but it only tells half the story. SVG is not a better PNG; it is a fundamentally different way of describing graphics, with its own strengths and a handful of pitfalls worth knowing before you ship a logo, an icon set or an illustration. This article covers when SVG is the right choice, when a raster format wins, and how to embed, optimise and secure it.
What SVG technically is
SVG stands for Scalable Vector Graphics and is a W3C recommendation. Version 1.0 appeared in September 2001; version 1.1, still the authoritative one today, followed in 2003 (second edition in 2011). SVG 2 has been in development for years but has still not been finalised as a recommendation, although browsers have adopted individual parts of it anyway.
The decisive difference from JPG, PNG or WebP: an SVG file contains no pixel grid but instructions – paths, circles, rectangles, text, colours, transformations – written as XML. When displaying it, the browser computes an image at exactly the resolution currently needed.
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24">
<path d="M12 2 L22 22 L2 22 Z" fill="currentColor"/>
</svg>This triangle is about 120 bytes and looks just as clean on a 5K display as on an old laptop. The most important attribute here is viewBox: it defines the internal coordinate system and is the prerequisite for the graphic scaling freely at all. Without a viewBox, an SVG behaves like a fixed-size image – the most common reason for "my SVG is suddenly not responsive".
Because SVG is plain text, it benefits enormously from transport compression. Gzip or Brotli squeeze XML markup down considerably, whereas PNG, WebP and AVIF are already compressed and barely shrink further over HTTP. An SVG weighing 8 kB uncompressed often arrives as a fraction of that – provided the server actually compresses image/svg+xml. This is one of the most frequently overlooked server settings.
SVG versus the raster formats
| Property | SVG | PNG | WebP | AVIF |
|---|---|---|---|---|
| Principle | vector (XML) | raster, lossless | raster, both | raster, both |
| Scaling | lossless at any size | blurry when scaled up | blurry | blurry |
| Transparency | yes | yes | yes | yes |
| Photographs | unsuitable | large | good | very good |
| Stylable via CSS | yes (inline) | no | no | no |
| Animatable | yes (CSS/SMIL) | no (APNG) | yes | yes |
| File size depends on | number of paths | pixel count | pixel count | pixel count |
| Needs srcset | no | yes | yes | yes |
The last two rows are the ones that matter. With raster images, file size grows with area: a logo at 1000 × 1000 pixels costs roughly four times as much as the same thing at 500 × 500, and high-density displays additionally require srcset and several variants. With SVG the display size is completely irrelevant to the file size – only the complexity of the drawing counts. One file, one request, every resolution.
But that is exactly where the limit comes from, too. An illustration with ten thousand paths, gradients and filters can run to several hundred kilobytes as SVG and cost the browser noticeable rendering time – raster images, by contrast, are decoded once and then done. And while a photograph can in theory be rebuilt from vectors, the result is always larger and worse than a JPG.
When SVG is the right choice
- Logos and wordmarks – they have to be sharp at every size, from favicon to hero section.
- Icons and UI symbols – few paths, often a single colour, ideal for
currentColorand theming. - Diagrams, charts, maps – geometric shapes with crisp edges, often generated dynamically.
- Flat illustrations – as long as the path count stays manageable.
- Decorative backgrounds and patterns – as a data URI directly in the CSS, with no extra request at all.
And when not:
- Photographs – always a raster format, AVIF or WebP when in doubt.
- Highly detailed vector artwork – beyond a certain complexity a pre-rendered PNG or WebP is smaller and faster.
- Graphics that need pixel precision at very small sizes – a 16-pixel icon drawn from an SVG designed for 48 pixels can look mushy, because the edges do not land on the pixel grid.
- Contexts without real SVG support – email clients are the classic problem case; for newsletters there is hardly a way around PNG.
The four ways to embed SVG
The method you pick decides styling, caching and security – and that is often underestimated.
| Method | Stylable via CSS | Scripts run | Cached separately | Typical use |
|---|---|---|---|---|
<img src="x.svg"> | no | no | yes | logos, static graphics |
| Inline in the HTML | yes | yes | no (part of the HTML) | icons, interactive graphics |
CSS background-image | no | no | yes | patterns, decoration |
<use href="sprite.svg#id"> | limited | no | yes | icon systems |
The key difference: an SVG in an <img> tag is treated by the browser like an ordinary image. It is self-contained, cannot load external resources, and any JavaScript it contains is not executed. The flip side is that the page's CSS cannot reach it either – changing colours is not possible.
Inline SVG is the opposite: fully part of the DOM, stylable via CSS (fill: currentColor being the classic), addressable from JavaScript – but also part of the HTML document. It is not cached separately and inflates every page response. For a handful of icons that is entirely fine; for thirty identical symbols on one page it is not.
Data URIs in CSS come with one trap: the # character has to be encoded as %23, otherwise the browser reads the rest as a fragment and the graphic stays invisible. Base64 is unnecessary here – URL-encoded SVG is smaller and stays readable.
Optimising SVG
SVG files exported from Illustrator, Figma or Inkscape routinely contain a multiple of what the browser needs: editor metadata, empty groups, unused <defs>, comments, layer names and path coordinates with six decimal places. The key steps:
- Clean up with SVGO. The standard tool strips metadata, merges paths and shortens numbers. It is available as a CLI, as a plugin for the common build tools, and as a web interface.
- Reduce path precision. Coordinates with six decimals are pointless in a 24-unit
viewBox; one or two are enough and save the bulk of the bytes on complex paths. - Keep the
viewBox, drop fixedwidth/height. Size belongs in the CSS, otherwise the graphic will not scale along. - Convert text to paths when type is involved. A
<text>element is rendered with whatever font the client happens to have – on other systems the logo then looks different. - Use
fill="currentColor"so icons inherit the text colour and follow dark mode automatically. - Enable gzip or Brotli for
image/svg+xml. The cheapest win available, and still forgotten in many configurations.
One note on ordering: optimise first, embed second. A data URI built from an uncleaned file drags all the editor ballast into every stylesheet.
The security angle
SVG is XML and may contain <script> elements, event handlers such as onload, and external references. That makes it powerful – and an attack vector as soon as third-party files are involved.
Concretely:
- Never inline an SVG from an unknown source into your HTML. Any JavaScript inside it then runs in the context of your own domain – textbook XSS.
- Inside an
<img>tag SVG is safe, because browsers allow no scripting there and block external resources. - Be careful with user uploads. If an uploaded SVG is opened directly under your own domain, the browser renders it as a document – scripts included. The usual countermeasures are a separate domain for user content, a forced download via
Content-Disposition, or server-side sanitising, for example with DOMPurify in SVG mode.
If you would rather not deal with these questions, there is a very simple alternative: rasterise the graphic. An SVG converted to PNG or JPG cannot contain a script by definition.
Accessibility and layout
Two details that are regularly missing in practice:
Semantics. An inline SVG is, to a screen reader, initially just a collection of shapes. Meaningful graphics need role="img" plus either a <title> element or an aria-label. Purely decorative graphics conversely get aria-hidden="true" so they are not announced. With <img src="x.svg"> the ordinary alt rule simply applies.
Layout stability. An SVG without reserved space shifts the content as it loads and worsens the Cumulative Layout Shift score. Either set width and height on the <img> element or define an aspect-ratio in the CSS. It costs nothing and prevents one of the most common Core Web Vitals penalties.
Fallbacks and rasterising
Browser support is effectively a non-issue: every browser still in use today renders SVG. Fallbacks are needed for other reasons:
- Social media preview images. Open Graph and Twitter Cards do not accept SVG.
og:imageneeds a PNG or JPG – 1200 × 630 pixels being the usual format. - Email. Many clients block SVG entirely. Newsletters need raster graphics.
- Favicons. Modern browsers accept SVG favicons, but especially in Windows contexts and on older clients an ICO file remains the safe route.
- Print and office workflows. Word, PowerPoint and various print services handle SVG with varying success; a high-resolution PNG is often the more pragmatic path.
For all of these you rasterise the SVG once at the size you need and keep serving the vector version alongside it. For the raster graphics on the site itself, the step to a modern format is then worth it – PNG to WebP regularly saves substantial bytes over PNG on flat graphics.
Frequently asked questions
Is SVG always smaller than PNG?
No. For logos and icons almost always; for complex illustrations often not. The rule of thumb: the fewer the paths and the larger the display area, the more clearly SVG wins. Beyond a few thousand paths, compare both variants – and measure the compressed size, not the one on disk.
Why does my SVG refuse to grow beyond a few pixels?
Almost always the viewBox is missing, or fixed width/height attributes are setting the size because no CSS overrides them. With a viewBox plus width: 100% in the CSS, the graphic scales as expected.
Why does my SVG logo look wrong on other people's devices?
Typically because the type was saved as a <text> element and the matching font is missing there. Converting type to paths fixes that permanently. The second most common cause is a missing xmlns attribute, without which some contexts do not recognise the file as SVG at all.
Can I animate SVG?
Yes – via CSS transitions and keyframes, via JavaScript, or via SMIL, which is built into SVG. CSS is the usual route today because it is widely supported and easy to debug. Animations are only controllable from the outside on inline SVG, though: external CSS does not reach into an <img> tag. CSS or SMIL animations defined inside the SVG itself do run there.
Is an icon sprite still worth it?
Under HTTP/2 and HTTP/3 the old "fewer requests" argument is largely obsolete. A sprite referenced via <use> still has a practical advantage, though: a single, separately cacheable file instead of the same path data repeated in every HTML document.
Conclusion
SVG is not an all-purpose format but the right tool for a clearly defined class of graphics: anything built from geometric shapes that has to stay sharp at several sizes. There it saves requests, variants and maintenance effort, and delivers the best rendering quality technically possible along the way. For photographs and very complex illustrations, raster formats remain unbeaten.
The three things that trip SVG up in practice are almost always the same: a missing viewBox, uncleaned export files, and a server that does not compress image/svg+xml. Tick off those three, convert type to paths, and never inline a third-party SVG unchecked, and you have the format under control.
Convert graphics with wandlio
Tools for working with SVG and raster graphics:
- SVG → PNG: rasterise vector artwork with transparency, e.g. for social previews
- SVG → JPG: rasterise for contexts without transparency or SVG support
- PNG → WebP: shrink rasterised graphics for the web
- PNG → ICO: produce a favicon for older browsers and Windows contexts
- Image → WebP: bring any raster format into the modern web format
Image conversions at wandlio run directly in your browser – the file never leaves your device.