SVG on the web: when vectors beat pixels
23 Sep 2026 · Images · 7 min read
Every image format we've covered so far — JPEG, PNG, WebP — is a raster format: a grid of pixels, fixed at creation, that gets blurrier the more you enlarge it. SVG is the odd one out. It doesn't store pixels at all. It stores instructions — draw a circle here, a curve there, fill it with this colour — and the browser renders those instructions fresh at whatever size is needed. The result is an image that is perfectly sharp at 16 pixels and perfectly sharp at 16,000.
That property makes SVG the best choice for a large and important category of web imagery: logos, icons, diagrams, and simple illustrations. It also makes it a trap for everything else. This article explains where vectors win decisively, where they lose, and the practical details of using them well.
What "vector" actually means
An SVG file is, at heart, a text document. Open one in a text editor and you'll find human-readable markup describing shapes: rectangles, circles, paths, text, gradients. A simple icon might be a few hundred bytes of this markup. Because it's math rather than pixels, three remarkable things follow.
First, infinite scalability. Rendering at a new size means re-running the math, not stretching pixels, so edges stay razor-sharp at any dimension. The same file serves a 16-pixel favicon-ish icon and a billboard-sized hero graphic without any quality compromise — one file replaces the whole set of raster sizes you'd otherwise need.
Second, tiny file sizes for simple artwork. A company logo that needs 40 KB as a PNG might be 3 KB as an SVG. Icons routinely come in under a kilobyte each. For sites with dozens of icons, switching to SVG can cut icon payload by 90% or more — one of the cheapest performance wins available.
Third, it's code, so it's styleable. Because SVG lives in the document as markup, CSS can recolour it, animations can morph it, and JavaScript can manipulate it. A single icon file can appear in five different colours across your site just by changing a CSS variable — try doing that with a PNG without five separate files.
Where vectors win
- Logos. The canonical SVG use case. A logo must appear at many sizes — favicon, header, footer, print — and must always be crisp. SVG does all of them from one file.
- Icons. Interface icons are simple geometric shapes, which is exactly what vectors describe efficiently. Whole icon sets ship as a single SVG sprite or font-like collection.
- Diagrams and charts. Lines, boxes, arrows and labels are vector-native. Bonus: the text in an SVG chart stays selectable and accessible, unlike text baked into a PNG.
- Simple illustrations and patterns. Flat-design illustrations with solid colours compress beautifully as vectors. Decorative backgrounds and repeating patterns too.
- Anything needing runtime theming. Dark mode toggles, brand colour changes, hover states — all trivial when the artwork is markup.
Three situations where SVG is the wrong choice
Now the other side, because SVG enthusiasm tends to skip it. Vectors are the wrong tool in at least three common situations:
1. Photographs and photorealistic imagery. A photo contains millions of unpredictable pixel values; describing them as vector shapes would require millions of shapes, producing a file larger than the JPEG, not smaller. There are "vectorised photo" filters that posterise images into flat regions, but that's a stylistic effect, not a faithful representation. If it came from a camera, it stays raster.
2. Complex, textured artwork. Even non-photographic images can defeat vectors. A detailed digital painting with thousands of brush strokes, grain and texture becomes an SVG with tens of thousands of path elements — a file that is both enormous and slow for the browser to render. Complexity has a crossover point, and past it, a well-compressed WebP wins on every axis: size, render speed, simplicity.
3. Untrusted uploads. This one is a security matter, not an aesthetic one. Because SVG is executable markup, it can contain JavaScript — and an SVG opened directly in a browser runs that script. Allowing users to upload SVG files that other users then view is a textbook cross-site scripting vector. If your site accepts user uploads, either rasterise SVGs to PNG on the server, serve them with a Content-Security-Policy that blocks scripts, or reject them outright. Never treat SVG as "just an image."
Practical notes for using SVG well
- Always set dimensions. An SVG without width and height (or a viewBox with CSS sizing) leaves the browser guessing, and different browsers guess differently. Include a viewBox and explicit dimensions or CSS rules.
- Optimise before shipping. Editor-exported SVGs are full of cruft: unused definitions, editor metadata, excessive decimal precision. Running them through an optimiser typically cuts 30–60% with zero visual change. (Decimal precision of 1–2 places is plenty for screen work.)
- Consider SVGZ for the truly size-conscious. SVG compresses extremely well with gzip — typically 60–80% smaller — and most servers can serve pre-compressed .svgz files with the right content encoding. In practice, though, standard HTTP compression (which your Hostinger plan almost certainly applies automatically) achieves the same result transparently, so SVGZ is rarely worth the extra configuration nowadays.
- Convert text to outlines for logos. SVG <text> renders in the viewer's fonts, which vary by system. For a logo that must look identical everywhere, convert lettering to paths — at the cost of larger files and lost selectability. Body text in diagrams can stay as text.
- Raster fallbacks are rarely needed anymore. Every current browser renders SVG natively and has for over a decade. The old advice about PNG fallbacks is obsolete for the public web.
- Converting SVG to raster has rules. When you do need pixels from a vector — a favicon from a logo, say — render from the SVG at the exact target size rather than rendering big and shrinking. And note that some converters need the SVG to carry explicit width and height to work at all.
- One SVG can serve your whole icon set. A common pattern is the SVG sprite: all your icons as <symbol> elements in a single hidden SVG file, referenced with <use href="#icon-name"> wherever needed. One HTTP request, one cached file, every icon on the site — and each instance independently styleable with CSS.
The honest caveat
Two final cautions. First, SVG is not automatically small. A hand-crafted icon is bytes; an auto-traced illustration with 50,000 nodes is megabytes and will make low-end phones stutter while rendering it. Vector efficiency depends entirely on the artwork being genuinely simple. When in doubt, compare the optimised SVG's file size against a WebP export at the largest size you'll display — let the numbers decide, not the ideology.
Second, rendering consistency is very good but not perfect. Complex filters, blend modes and exotic features can render slightly differently across browsers, and SVG fonts remain a perennial source of cross-platform variation. For mission-critical artwork, test in the browsers your audience actually uses — which, for most sites, means current Chrome, Safari and Firefox, where SVG behaviour is thoroughly settled.
Used where it belongs — logos, icons, diagrams, simple illustration — SVG is the closest thing web imagery has to a free lunch: smaller files, perfect sharpness, effortless theming. Used where it doesn't belong, it's a performance and security headache. The format isn't magic. It's just math, applied to the right problems.