Inside an SVG file: viewBox, paths and how to clean it up

SVG (Scalable Vector Graphics) is an XML-based vector format. Its most valuable feature is also the most overlooked: it is text. You can open it in any editor, read it, fix it by hand and compare versions. Once you learn to read it, you stop treating SVGs as black boxes and solve in minutes problems that would otherwise mean reopening the file in a graphics program.

The minimal skeleton

Here is a complete, valid SVG that draws a blue circle with an orange square:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100" width="200" height="200">
  <circle cx="35" cy="50" r="25" fill="#1e5aa8"/>
  <rect x="55" y="30" width="40" height="40" fill="#e07b1f"/>
</svg>

Three things to notice straight away:

• The xmlns attribute declares the namespace: without it, opened as a standalone file, the SVG may not be recognised.
• Shapes are elements with explicit geometric attributes.
• width and height say how large to display the image; viewBox says which portion of the plane to draw.

The viewBox, the key concept

The viewBox has four numbers: minimum x, minimum y, width, height. It defines a "window" onto the internal coordinate system, which is then fitted to the display area. In the example, the plane runs from 0 to 100 in both directions and is shown in a 200 × 200 box: each internal unit becomes two pixels.

This mechanism is what makes SVG scalable. If you omit width and height and keep only the viewBox, the image adapts to its container. If the viewBox is missing, the SVG does not know how to scale and is cropped or stays at a fixed size: one of the most common reasons icons refuse to resize.

When the proportions of the viewBox and the box differ, preserveAspectRatio steps in, deciding whether to fit, center or crop. The default centers the drawing while keeping its proportions.

The language of paths

Complex shapes are described with the path element and its d attribute, which holds a mini-syntax of commands:

Uppercase letters use absolute coordinates, lowercase ones coordinates relative to the current point. A triangle, for example, is M10 90 L50 10 L90 90 Z. Optimisers favour relative coordinates because they produce shorter numbers.

Groups, transforms, reuse

• <g> groups elements and lets you apply a style or transform to all of them.
• transform accepts translate, rotate, scale, skewX, skewY and matrix. Transforms compose and are applied right to left relative to the element.
• <defs> holds elements that are not drawn directly: gradients, masks, clipping paths, symbols.
• <symbol> and <use> let you define a drawing once and reuse it many times: the principle behind icon "sprites".

Styles can be written as attributes (fill="red") or as CSS, inside the file or, if the SVG is inlined in a page, inherited from the page. This makes it possible, for example, to color an icon with fill="currentColor" so it takes the color of the surrounding text.

What editors leave inside an SVG

Exporting from a graphics program often yields a file far heavier than necessary. Opening it, you typically find:

• editor metadata, comments and proprietary namespaces;
• coordinates with six or more decimals, useless for an icon;
• empty nested groups or groups with a single child;
• accumulated transforms that could be applied directly to the coordinates;
• raster images embedded in base64, sometimes without the exporter knowing;
• long IDs that are never used.

Cleaning up an SVG step by step

In my work I follow a simple procedure:

1. I check the viewBox: it must exist and frame the drawing without random margins.
2. I look for embedded images: a data:image/png;base64 string inside a "vector" file almost always explains an unusual size.
3. I run an optimiser such as SVGO, with cautious settings, and compare the result visually.
4. I reduce precision to one or two decimals for simple icons and logos.
5. I convert text to paths if the file will be used where the font might be missing, keeping a copy with editable text.
6. I check accessibility: for meaningful SVGs I add a <title> element.

An icon exported at 8 KB often drops below 1 KB with no visible difference.

A note on security

Because it is XML, an SVG can contain scripts and external references. In web pages, when it is shown through an img element, scripts do not run; opened directly or inlined in the page's code, they do. That is why anyone accepting user-uploaded SVGs should sanitise them or convert them to raster before publishing.

In short

• An SVG is readable XML: it can be inspected and fixed with a text editor.
• The viewBox defines the internal coordinate system and is what makes the file scalable.
• The path d attribute uses short commands, absolute (uppercase) or relative (lowercase).
• Files exported by editors often contain metadata, decimals and embedded images to remove.
• SVGs uploaded by third parties must be sanitised because they can contain scripts.