Discover the Wonderful World of SVG

So you want to learn SVG. Good. Now is the right time. Not in five years, when your project contains four versions of every icon and somebody has created a spreadsheet to explain which PNG belongs to which screen density. Not after the next redesign. Not when the design team sends you a logo called logo_final_final_3x.png. Now.

SVG has been part of the web for a long time. The first public working draft appeared in 1999, and SVG 1.0 became a W3C Recommendation in 2001. It is not an experimental format waiting for permission to become useful. It is a standard language for describing two-dimensional vector graphics. The word language is important.

An SVG image is not merely a rectangular collection of colored pixels. It is a document made from elements, attributes, shapes, coordinates, styles, and relationships. Open the file in a text editor and you can read it. Insert it into an HTML document and the browser can expose its elements to CSS and JavaScript. Inspect it with developer tools and you can see how it was built.

This does not automatically make every SVG pleasant to read. Export one from a design application and you may receive a small XML novella written by a machine that appears to be billing by the <path>. Still, it is code. Useful, editable, scalable code.

Vector graphics without the ceremony

A JPEG, PNG, or WebP image normally describes a grid of pixels. Each pixel stores visual information for a specific position in that grid. If the image contains 500 by 500 pixels, that is the information available. You can display it at 1,000 by 1,000, but the browser cannot invent the missing detail. It must enlarge the existing pixels, interpolate between them, and hope nobody looks too closely. SVG works differently.

Instead of storing the final pixels, it describes the geometry required to produce them. A circle is defined by its center and radius. A rectangle has a position, width, and height. A polygon is a series of connected points. A path contains instructions for lines and curves. The browser takes those instructions and renders the result at the required size.

That is why a properly constructed SVG can appear sharp on a small phone, a high-density laptop display, a large monitor, or a printed poster. The same geometry is rendered for the available output instead of enlarging a fixed bitmap. This is usually described as resolution independence. It is one of SVG’s most obvious advantages, but not its only one.

The format can also be styled, searched, compressed, reused, animated, made interactive, and generated programmatically. Individual parts of an illustration can have their own identifiers and accessible descriptions. A PNG is an image. An SVG can be an image, a document, and, when someone becomes too enthusiastic, a small application.

The simplest useful SVG

You do not need Illustrator, Inkscape, Sketch, or any other graphical tool to create your first SVG. A text editor is enough.

Here is a complete example:

<svg
  xmlns="http://www.w3.org/2000/svg"
  viewBox="0 0 500 500"
  role="img"
  aria-labelledby="pentagon-title pentagon-description"
>
  <title id="pentagon-title">Black pentagon</title>
  <desc id="pentagon-description">
    A five-sided black polygon drawn on a square canvas.
  </desc>

  <polygon points="30,100 30,468 473,468 473,218 302,30" />
</svg>

Save it as pentagon.svg and open it in a browser. That is all. No XML declaration is required for a normal web SVG. You do not need the old SVG 1.1 DOCTYPE. You do not need a version attribute for modern use, and you certainly do not need six lines of ceremonial metadata before drawing one polygon. The root <svg> element defines the document. The xmlns attribute identifies the SVG namespace. The viewBox establishes the internal coordinate system, and the <polygon> contains the actual shape.

The <title> and <desc> elements provide an accessible name and description. MDN documents both <title> and <desc>, although the exact accessibility strategy depends on how the image is embedded and whether nearby visible text already describes it. The old version of this example was much longer. The graphic was not better. It simply arrived with more paperwork.

Understanding viewBox

The most important attribute in that example is probably this one:

viewBox="0 0 500 500"

The four numbers mean:

minimum-x minimum-y width height

In this case, the internal coordinate system begins at 0,0 and covers an area 500 units wide by 500 units high.

Notice that I said units, not pixels.

An SVG user unit is part of the document’s coordinate system. The browser maps that coordinate system into the available viewport. If the SVG is displayed at 250 pixels wide, the 500-unit drawing is scaled down. If it is displayed at 1,000 pixels wide, it is scaled up. The geometry remains the same. The W3C specification describes viewBox as the mechanism that maps an SVG region into its viewport, normally working together with preserveAspectRatio. (W3C explains the full coordinate system here.)

This means you can write:

<img
  src="/images/pentagon.svg"
  alt="Black pentagon"
  width="200"
/>

And later display the same file at 800 pixels wide without exporting another version. There is no pentagon@2x.svg. There is no pentagon-retina-final.svg. There is just geometry. A rare moment of peace in front-end development.

How polygon points work

The polygon in the example contains this sequence:

<polygon points="30,100 30,468 473,468 473,218 302,30" />

Each pair represents an x,y coordinate. The first point is located at x = 30 and y = 100. The next is at 30,468, followed by 473,468, and so on. The browser connects those points in the order they appear and then closes the final segment back to the first point. That order matters. Reversing the complete sequence may produce the same outline with the opposite winding direction, but rearranging points arbitrarily can create a different shape, crossed lines, or something that looks like the polygon had a difficult evening.

Decimal coordinates are also valid:

<polygon points="30.25,100.5 30,468 473.75,468 473,218 302,30" />

Using decimals does not automatically make the result blurry. Rendering depends on scaling, transforms, stroke widths, and how the final geometry maps onto the physical pixel grid.

You normally do not need to micromanage this.

Describe the correct shape. Let the browser rasterize it for the display. Intervene when visual testing reveals a real issue, not because one coordinate contains the suspicious decimal .5.

The <polygon> specification defines the element as a closed shape made from connected coordinate pairs. For more complex geometry, SVG provides the much more powerful <path> element.

Basic shapes before paths

Most SVG tutorials reach <path> quickly because paths can draw almost anything.

That does not mean every shape should be a path.

SVG includes readable primitives for common geometry:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 320 120">
  <rect x="10" y="10" width="100" height="100" rx="12" />

  <circle cx="160" cy="60" r="50" />

  <line
    x1="220"
    y1="10"
    x2="310"
    y2="110"
    stroke="currentColor"
    stroke-width="8"
  />
</svg>

There are elements for rectangles, circles, ellipses, lines, polylines, polygons, text, images, groups, symbols, gradients, masks, patterns, filters, and more. The MDN SVG element reference is a good place to inspect them without reading the complete specification before breakfast.

Use the clearest element that describes the geometry.

A circle represented by <circle> is easy to understand and modify. The same circle represented by a generated path with sixteen decimal values is technically correct and emotionally hostile.

Paths become valuable when a shape contains arbitrary lines, Bézier curves, or arcs. They are essential for detailed illustrations and logos, but they should not be treated as proof that the SVG is more professional.

Complexity is not a visual feature.

Styling SVG with CSS

SVG presentation attributes often look similar to CSS because many of them correspond directly to CSS properties:

<circle
  cx="50"
  cy="50"
  r="40"
  fill="#ffd700"
  stroke="#003b73"
  stroke-width="6"
/>

You can also use a style attribute:

<circle
  cx="50"
  cy="50"
  r="40"
  style="fill: #ffd700; stroke: #003b73; stroke-width: 6"
/>

Or, when the SVG is inline in the HTML document, you can apply normal CSS:

<svg
  class="club-badge"
  viewBox="0 0 100 100"
  aria-label="Decorative club badge"
  role="img"
>
  <circle class="club-badge__background" cx="50" cy="50" r="45" />
  <path class="club-badge__detail" d="..." />
</svg>

.club-badge__background {
  fill: #003b73;
}

.club-badge__detail {
  fill: #ffd700;
}

For icons, one particularly useful value is currentColor:

<svg viewBox="0 0 24 24" aria-hidden="true">
  <path fill="currentColor" d="..." />
</svg>

The icon now inherits the surrounding text color:

.button {
  color: navy;
}

This lets the same SVG work in buttons, links, dark themes, hover states, and disabled states without exporting five separate files. You can also animate supported properties and transforms with CSS. That does not mean every icon should spin when the pointer passes nearby. Capability remains different from judgment.

Four ways to place SVG on a page

SVG can be included in several ways, and the correct choice depends on what you need from it.

As a normal image

<img
  src="/images/logo.svg"
  alt="Company name"
  width="180"
  height="48"
/>

This is often the best choice for a static logo, illustration, or decorative asset. The browser can cache the file. The markup remains simple. The SVG behaves like any other image, and the page does not need to know about its internal elements. The disadvantage is that page-level CSS and JavaScript cannot normally manipulate the individual shapes inside it. That is often fine. Not every logo needs a personal relationship with the DOM.

Inline in the HTML

<svg viewBox="0 0 24 24" aria-hidden="true">
  <path fill="currentColor" d="..." />
</svg>

Inline SVG gives the page access to the internal elements. CSS can style them, JavaScript can manipulate them, and the SVG can participate directly in the document’s accessibility tree. This is useful for icons, data visualizations, diagrams, or graphics whose appearance changes according to application state. The cost is more HTML, less straightforward caching, and the temptation to turn a simple icon into a component with seventeen configuration properties.

MDN has a practical guide to using SVG inline in HTML.

As a CSS background

.hero {
  background-image: url("/images/pattern.svg");
}

This works well for decorative images that do not convey content. Because CSS backgrounds have no useful alternative text, do not use them for an image the reader needs to understand.

As a reusable symbol

For interface icons, you can define symbols and create instances with <use>:

<svg aria-hidden="true" hidden>
  <symbol id="icon-search" viewBox="0 0 24 24">
    <path d="..." />
  </symbol>
</svg>

<svg aria-hidden="true">
  <use href="#icon-search"></use>
</svg>

This can reduce repeated markup and provide a small icon system. External symbol files are also possible, although browsers apply same-origin and security restrictions in some situations. MDN documents those details in the <use> reference.

There is no universally superior embedding method. Use <img> when the SVG is simply an image. Use inline SVG when you need access to its structure. Use CSS for decoration. Use symbols when reuse genuinely simplifies the interface. Do not choose inline SVG merely because it feels more advanced. The browser will not promote you.

SVG and accessibility

Vector graphics do not become accessible merely because they contain XML. An SVG may be decorative, informative, interactive, or a mixture of all three. The implementation should reflect its purpose.

For a normal SVG referenced through <img>, use meaningful alternative text:

<img
  src="/charts/revenue.svg"
  alt="Revenue increased from $2 million to $3.4 million between 2024 and 2025."
/>

For a decorative image, use an empty alternative:

<img src="/images/divider.svg" alt="" />

For inline SVG, a simple informative graphic can use role="img" with a label:

<svg
  viewBox="0 0 100 100"
  role="img"
  aria-labelledby="chart-title chart-description"
>
  <title id="chart-title">Quarterly revenue</title>
  <desc id="chart-description">
    Revenue increased in each of the four quarters.
  </desc>

  <!-- chart elements -->
</svg>

Complex charts may require visible summaries, data tables, keyboard interaction, or descriptions outside the SVG. A hidden sentence inside <desc> cannot make a deeply interactive visualization usable by itself.

Accessibility is not a metadata side quest. It is part of deciding what the graphic means and how someone can obtain the same information without seeing or pointing at it.

SVG is not always the right format

SVG is excellent for:

• Logos.
• Icons.
• Diagrams.
• Maps.
• Charts.
• Geometric illustrations.
• Interface decoration.
• Graphics that need to change color or scale.
• Images generated from structured data.

It is usually not the best format for photographs or richly textured raster artwork.

A photograph contains enormous variation in color and detail. Describing all of that through vector shapes can produce a file that is larger, slower, and more complicated than an ordinary raster image. You can convert a photograph to SVG. You can also transport a refrigerator by bicycle. The interesting question is why.

Use JPEG, WebP, AVIF, or another suitable raster format for photographic material. Use PNG when you need lossless raster graphics or particular transparency behavior. Use SVG when the image is naturally described as shapes, lines, text, and curves. Do not select formats by ideology. Select them according to the content and how the product needs to use it.

File size is not automatically small

People often say SVG files are smaller than PNGs. Sometimes they are. A clean icon or simple logo can be tiny. A detailed illustration exported by a design tool can contain unnecessary groups, metadata, hidden layers, duplicated styles, excessive coordinate precision, and paths detailed enough to record the artist’s pulse. The result may be larger than the raster equivalent. Inspect exported SVGs.

Remove unused elements and editor metadata. Simplify geometry when the visual difference is negligible. Reuse styles. Reduce unnecessary decimal precision. Compress the file when it makes sense. Tools can help, but optimization should not be blind. An optimizer may remove identifiers, titles, groups, or precision that your application depends on.

The smallest file is not automatically the best file. A maintainable SVG that is one kilobyte larger may be preferable to a compressed puzzle nobody can safely edit. Performance is a trade-off, not a competition to see who can produce the least readable markup.

SVG can contain more than graphics

SVG is powerful partly because it is an active document format. Depending on how it is loaded, it may contain links, styles, references to external resources, animation, and scripts. Inline SVG participates in the surrounding page and can be manipulated like other document content.

This has a simple security consequence: Do not insert untrusted SVG markup directly into your page. Treat user-provided SVG as potentially active content. Sanitize it with a tool designed for the job, convert it to a safe raster image, or serve it in a context where browser restrictions prevent scripts and external resources from running.

SVG loaded through <img> is normally subject to additional browser security restrictions. MDN notes that scripting and external resource loading are disabled in image contexts, while those restrictions do not necessarily apply when the SVG is embedded as a document or placed inline. (Read “SVG as an image” for the exact distinctions.)

The fact that a file ends in .svg does not make it harmless. HTML also looks like text. We have seen how that turned out.

A brief history without mythology

SVG was not created from one proposal by one company. During the late 1990s, several organizations submitted competing vector-graphics proposals to the W3C. PGML came from Adobe, IBM, Netscape, and Sun. VML came from Microsoft, Autodesk, Hewlett-Packard, Macromedia, and others.

The final standard drew ideas from several of those efforts. The W3C has documented this history in “The Secret Origin of SVG”, including the influence of PGML and VML on the language that followed.

The first public SVG working draft appeared in February 1999. SVG 1.0 became a W3C Recommendation on September 4, 2001, with the announcement published the following day. The standard has evolved since then, but the important idea has remained stable: describe graphics through structured, scalable, web-compatible primitives. That idea aged well.

The XML enthusiasm surrounding the original format may feel like a postcard from another era, but SVG itself survived because it solves a real problem and integrates with the platform instead of fighting it.

Browser support is no longer the interesting question

When I first wrote about SVG, compatibility tables were necessary. Using the format often required checking specific browser versions and preparing fallbacks for older systems. That concern has mostly moved on. Basic SVG support is now a normal part of the browser platform. The useful questions are no longer whether a browser can display a circle or polygon.

The questions are:

How are you embedding the SVG?

Does the particular filter, animation, or feature work in the browsers you support?

Is the image accessible?

Can it be cached?

Is it safe?

Is the exported file unnecessarily large?

Does the SVG need to be interactive at all?

The MDN SVG documentation provides tutorials, element references, guides, and compatibility information for individual features. The SVG 2 specification remains the authoritative technical reference when you need to discover what the language actually says rather than what a twelve-year-old forum answer vaguely remembers.

You do not need to memorize the entire specification. Nobody needs that kind of weekend.

Learn the coordinate system. Understand viewBox. Practice the basic shapes. Learn enough path syntax to recognize what you are looking at. Try inline SVG and an ordinary <img>. Style an icon with currentColor. That will already take you surprisingly far.

Start using it

SVG is not the future. It is part of the web we already have. Use it for the next icon instead of exporting another set of density-specific PNGs. Open the file in a text editor. Remove what you do not need. Change a color with CSS. Add a title when the graphic needs one. Resize it until you become bored and confirm that it remains sharp. Then build something slightly more interesting. Create a diagram. Generate a chart from data. Animate one transition, quietly. Inspect how paths work. Try a mask or a gradient.

The goal is not to replace every image on your website with SVG. The goal is to recognize the cases where vectors give you a cleaner, more adaptable, and more maintainable result. It is a powerful format, but it is still a tool. Use it where it earns its place.

And please, before sending the logo to engineering, open the exported file once. If it contains 4,000 paths for a blue circle, we need to have a conversation.