What is an SVG, and why is it worth using?

There is a request we make in the first week of almost every project: “send us the logo as an SVG”. And there is an answer that comes back more often than it should: “here is the PNG in high resolution, it looks great”.

They are not the same, and the difference shows up exactly when it is too late: in the site header, at the foot of an invoice, on a sign, in the favicon.

Pixels versus instructions

A PNG or a JPG stores pixels: a grid of coloured dots. When you enlarge them, the browser invents the dots that are missing, and that is what reads as blurry or jagged.

An SVG stores no pixels. It stores drawing instructions: “a line from here to here”, “a curve with this shape”, “fill with this colour”. The browser executes them at whatever size is needed, so the result is sharp in a 16-pixel favicon and on a billboard, from the same file.

Three practical consequences follow:

• It weighs little. A typical logo takes a few kilobytes, far less than its PNG equivalent at large sizes.
• It is text. An SVG opens in a code editor, diffs in version control, and can be generated from a script. It is the only image format whose changes you can actually read.
• The site can change it. Colours, stroke weights and animation are controlled with CSS. An icon inheriting the text colour through currentColor needs no light and dark variants: it adapts to the theme on its own.

When yes, and when no?

Yes: logos, icons, line or flat illustrations, charts and diagrams, patterns, maps.

No: photographs. An SVG can carry a photo inside it, but that is putting a bitmap in a vector box: it weighs the same or more and gains no sharpness. For photos, WebP or AVIF.

The practical boundary is simple: if someone drew it with shapes, it is an SVG; if a camera captured it, it is not.

One case almost nobody considers: QR codes. A QR code is a matrix of squares, so as an SVG it prints sharp at any size, while an enlarged PNG leaves jagged edges and makes scanning harder. It is covered in how QR codes work.

Why does the SVG you export weigh ten times what it should?

This is where most people are surprised. A simple icon exported from a design tool can take 40 KB when its clean version is 3 KB. It is not that the drawing is complex: it is everything the editor leaves inside.

Editor metadata. Whole blocks describing which program generated it, at which version, on which date and with which layer name. None of that is drawn.

Absurd precision. Coordinates like 12.000000000000002 when 12 produces the same pixel on screen. Every leftover decimal is bytes multiplied across hundreds of points.

Dead structure. Empty groups, hidden layers somebody switched off, gradient definitions nothing uses any more, attributes repeated on every element instead of inherited.

Duplicated styles. The same fill declared fifty times instead of once.

What can be removed, and what cannot?

Optimising an SVG is mostly deleting. But there are four things you must not touch, and seeing them broken is more common than it sounds:

1. The viewBox. It is what tells the browser the drawing’s proportions and lets it scale. Without a viewBox, an SVG stops being flexible and shows up at a fixed size.
2. Referenced ids. If your CSS or JavaScript targets an element by id, or a gradient is referenced from elsewhere, renaming them breaks the drawing or its behaviour.
3. title and desc. They are the SVG’s accessibility: what a screen reader announces. A logo with no title is a mute image.
4. Meaningful groups. If you plan to animate one piece, that piece has to keep existing as its own element.

That is why it is worth checking the result and not only the file size. Our SVG optimizer does exactly that: it shrinks the file and shows before and after superimposed so you can see whether anything moved. The comparison matters more than the percentage saved.

How do you put it on the page?

Two ways, and the choice is not a matter of taste:

With <img src="logo.svg"> when the image stands alone and you do not need to style it from the site. It caches like any file, keeps your HTML clean, and — an important detail — the browser does not execute any JavaScript it might contain.

Inline, pasting the <svg> into the HTML, when you need CSS control: icons that change colour on hover, charts that react to dark mode, animated parts. The cost is that the code travels with every page that uses it.

A security warning almost nobody gives

An SVG is a document, not an inert image: it can contain scripts and external references. If your application allows file uploads and accepts SVG — profile pictures, client logos, attachments — you are accepting code.

The two reasonable defences: sanitise the file on the server before storing it, and always serve it inside an <img> tag, which treats it as an image and executes nothing. For your own SVGs, the ones you control, this does not apply.

---

In short: always ask for the logo as an SVG, keep it with the rest of the code, clean it before publishing, and check with your own eyes that it is still the same drawing. Fifteen minutes once, and in exchange you get a brand that stays sharp everywhere for years.