What Is an SVG, Really? Inside the Markup

A minimal SVG that draws a red circle is about eighty bytes of text. Open it in a text editor and you can read every decision that produced the image: the canvas size, the coordinate window, the shape, and the paint. No other common image format offers this, and that transparency is both why SVG is so useful and why it confuses people who expect an image file to be opaque.

SVG stands for Scalable Vector Graphics. It is a W3C recommendation, currently at SVG 2 with SVG 1.1 as the widely implemented baseline, and it is an XML application — its syntax rules come from XML, and its rendering model is defined separately in the specification.

What is actually inside the file

Every SVG begins with an XML declaration and a root <svg> element that carries the xmlns namespace. Inside, the document is a tree of elements: shapes, groups, definitions, and paint references. Nothing is stored as an image; everything is stored as instructions.

Here is the anatomy, shape by shape.

Why shapes are not the same as outlines

A <circle> with radius 50 is a mathematically perfect circle. A <path> that looks like a circle is four cubic Bézier segments approximating one. Visually identical at normal sizes, but not identical objects. Cutters and CAM tools care about this because a circle can be cut as a single arc move, while an approximated circle becomes a dense polyline.

The same holds for stroked versus filled geometry. A 1 mm stroke is paint applied along a zero-width path, not a 1 mm wide band of geometry. Software that reads strokes as cuts behaves differently from software that reads fills as cuts, which is why layer conventions matter so much. Our laser cutting guide explains the conventions in detail.

The coordinate system and the viewBox

This is the part that causes nearly every scaling problem. Two things define the geometry-to-canvas mapping.

width and height describe the canvas — the box the SVG occupies in its container. They can be in user units, or in real units such as mm, cm, in, pt, px. When expressed in real units they are tied to the CSS definition of that unit: one inch equals 96 CSS pixels.

viewBox describes the internal coordinate window, as four numbers: minimum x, minimum y, width, and height. It says "the drawing inside this document lives between these coordinates." Everything in the file is positioned relative to that window.

The viewBox is then fitted to the canvas using the preserveAspectRatio rule, which by default is xMidYMid meet — scale uniformly to fit, centre it, and add empty space if the aspect ratios differ.

Why this matters for machines

A document with a viewBox of 0 0 100 100 and no width or height has no physical size at all. A browser will size it to its container. Illustrator will open it at 100 points. A laser cutter's importer will often assume 100 millimetres.

A document with width="100mm" height="100mm" and the same viewBox is unambiguous: 100 millimetres, with one user unit equal to one millimetre. That version behaves correctly almost everywhere.

The recommended pattern for anything destined for a machine is therefore explicit dimensions in the physical unit plus a viewBox with matching numbers, so the user-unit-to-millimetre ratio is exactly 1:1. Our SVG versus DXF comparison covers what happens when a file without that is handed to CAD.

Presentation and structure

SVG separates content from style in the same way HTML does. A shape's fill can be set as a presentation attribute, presented as CSS in a <style> block, or applied by inline style attribute. All three are valid; the cascade decides the winner, with the inline style highest priority after important declarations.

That flexibility is a problem in practice. Many importers — cutting software, CAD tools, some office suites — read only presentation attributes and ignore CSS entirely. If your file's colours come from a <style> block, those importers may render everything black or drop it. For machine-bound files, prefer presentation attributes on the elements themselves.

Groups, transforms and inheritance

A <g> element groups children and applies its attributes to them. If a group has fill="red", every child without its own fill is red. If a group has transform="translate(10 20) scale(2)", every child coordinate is scaled and offset by that matrix, and transforms nest multiplicatively.

Nested transforms are the second most common source of surprise after missing units. A shape may say it is 5 units wide, but three ancestor transforms can make it 200 units wide on screen. Most conversion tools flatten transforms before writing other formats, which is correct — but only if the flattening respects the whole ancestor chain. Optimising an SVG usually includes exactly this step.

Using <use> to instance repeated definitions is elegant in a browser and poorly supported in CAD and cutting software, which may render every instance from the original position — stacking copies on top of each other. For machine output, expand <use> before export.

Painting: fills, strokes, gradients

Fills can be a solid colour, a gradient, or a pattern. Both linearGradient and radialGradient live in <defs> or anywhere else and are referenced with url(#id). Patterns work the same way.

Strokes add width, linecap, linejoin, dasharray and dashoffset. A dashed stroke is an instruction to the renderer, not geometry. Convert a dashed line to DXF and you get either a solid line or a long series of individual dashes, depending on the converter, and only one of those is what you wanted.

Filters — blur, drop shadow, displacement maps — are also part of the language, backed by SVG filter primitives. They are expensive to render and unsupported by almost every non-browser consumer. Rasterise anything that depends on a filter before sending it anywhere that is not a browser.

Nesting and the coordinate stack

Every element that can hold children can establish a new coordinate system, and those systems stack. A translate on the root shifts everything below it; a scale on a group inside multiplies everything below that; a rotate on a single path applies only to that path. The transform attribute takes a list of matrix operations applied left to right, which contradicts most people's intuition about order until they work through an example.

The transform translate(50 0) rotate(30) means: first rotate the coordinate system by 30 degrees, then translate 50 units along the rotated x axis. Reverse the order and the shape lands somewhere entirely different. Design tools hide this, but exporters write it out literally, and any tool that reads the file sees the matrices as given.

Most converters flatten transforms before writing another format, which resolves the ambiguity. It also means the output has no structure left, so if you need machine-readable groups in the destination, name them before flattening.

Clipping and masking

A clipPath restricts where a shape can paint. It takes any shape as a boundary and clips children to the region inside it. A mask does the same thing but with alpha, so a gradient mask fades content out rather than cutting it hard. Both are structural and neither survives most machine-bound conversions, because a cutter has no notion of a region that partially shows artwork.

In practice, a design file with four clip paths and two masks will convert to either flattened geometry, if the tool is good, or to visibly wrong geometry, if it is not. Check before sending.

Text, fonts and control

The text element places glyphs at coordinates and lets the layout engine do the rest. Characters can be positioned precisely with x and y lists, spaced with dx and dy lists, or rotated with a rotate list. Combined with text-anchor, alignment works reasonably.

That flexibility is exactly why text is the most fragile part of an SVG. The font is a reference, not data, unless it has been converted to paths. A browser substitutes, an application prompts, and a cutting machine ignores it. Designers who deliver files for production almost always convert type to outlines at the last step — which keeps a working copy with live text elsewhere.

Accessibility considerations

An inline SVG is part of the document tree, so its title and desc elements can be announced by assistive technology, and shapes can receive focus and ARIA roles. That makes SVG materially better than a PNG for any graphic that conveys information. Use a title as the accessible name and desc for a longer explanation; leave decorative graphics without them so screen readers skip them.

Storage and delivery

SVG compresses well because it is repetitive text, and most servers gzip it automatically. A 20 KB raw SVG often arrives as 5 KB over the wire. That, combined with caching, makes it the cheapest way to ship sharp artwork over a network — a point worth weighing against the tracing-size caveat in PNG versus SVG.

What SVG deliberately does not do

There is no CMYK colour space, no spot inks, no bleed box, and no page model beyond the single canvas. That is not an oversight; the format was specified for the web, where those concepts do not apply. When a job needs them, PDF is the format — see SVG versus PDF for print.

SVG also has no built-in notion of layers. Grouping is the closest equivalent, and some applications read inkscape:groupmode="layer" or data-name attributes, but the specification knows nothing about them.

For the surrounding landscape, see the practical map of vector file formats. If you have a bitmap rather than an SVG, PNG to SVG is the entry point, and SVG to PNG produces a raster at a size you choose.

One more practical note: because SVG is XML, it can carry scripts and external references. That is legitimate for interactive graphics and a genuine risk for upload pipelines — covered in SVG security.