We've covered "inline SVG" - which is dropping the SVG syntax right into HTML. You can use that same inline SVG in other places as well, like in an <img> or background-image. It's pretty weird.

It's like:

<img src='data:image/svg+xml;utf8,<svg ... > ... </svg>'>

You drop the entire SVG syntax in there where you see the <svg> start there.

Likewise in CSS:

.bg {
  background: url('data:image/svg+xml;utf8,<svg ...> ... </svg>');

Beyond that, you can convert SVG into Base64 encoding, and that works as the Data URI as well, like:

<img alt="" src="data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDo etc">

And that works in CSS as well (probably other places, anywhere you would use a graphic.)

See the Pen SVG using Data URI (Multiple Ways) by Chris Coyier (@chriscoyier) on CodePen.


  1. User Avatar
    Permalink to comment#

    I’m unsure what the advantages are when using data:image/svg+xml;utf8 compared to using just an inline SVG?

    • User Avatar
      Chris Coyier
      Permalink to comment#

      One potential thing is DOM weight. With inline SVG, all the shapes are in the DOM, where as an <img> is just that one DOM node.

    • User Avatar
      John Moore
      Permalink to comment#

      We use data uris for icons that are repeated. You can have a CSS class that you can apply to everywhere you want the image. If you’re trying to squeeze out every tiny bit of performance, it can be a good strategy.

  2. User Avatar
    Jonathan Duck
    Permalink to comment#

    Base64 is an encoding.

    UTF-8 mainly uses 1 byte (a number from 0-255) for each character. (This assumes you are using only characters that don’t need more, like those in a typical SVG.) Base64 can take any binary data, like an SVG text file or an image file and use 64 different characters to encode that data.

    Hello becomes SGVsbG8K, and 'I just broke CSS; becomes J0kganVzdCBicm9rZSBDU1M7Cg==, which can be put in a CSS string.

    It will always make your file bigger, but will ensure you can put it anywhere use can use the 64 characters of base64. In CSS, your linebreaks break the document, but in base64 they are encoded, so there is no issue. It is mainly useful for files that have characters you can’t put in your document. Opening an PNG in your text editor and trying to copy and paste it into a CSS file is not likely to end well. ;)

  3. User Avatar
    Adam Crockett

    How about base 64 encoded svg filters in files… Then webpack them into filter:url(require(‘blur.svg’)); – Now that’s a use case right there. Css backdrop filter early anyone?

  4. User Avatar
    Permalink to comment#

    list-style-image is working fine with the below code but hover is not working. hover is working when tags in html but not CSS, any solution would be great help. thanks in advance.

    .dropdownList ul{
    display: none;
    list-style-image: url("data:image/svg+xml;utf8,");
    list-style-position: inside;
    .dropdownList li:hover  svg #circle{
    fill: #fce57e;
  5. User Avatar
    Permalink to comment#

    Base64 encoding isn’t the only available choice. For example, by default it expects URI encoding. If you took it into your head, you could URI-encode an entire SVG file. If you’re already using a preprocessor like LESS or SASS, there may not be much benefit to doing it that way. Without a preprocessor, URI-encoding makes it less somewhat less cumbersome to futz with color values. This can be a sanity saver if you’re working with an irresolute designer.

  6. User Avatar
    David E Elliott
    Permalink to comment#

    If I generate an SVG icon, save the base64 encoded string and use that string in a thousand img tags, does the browser have to decode the string and reparse the SVG for each img tag?

Leave a Comment

Posting Code!

You may write comments in Markdown. This makes code easy to post, as you can write inline code like `<div>this</div>` or multiline blocks of code in triple backtick fences (```) with double new lines before and after.

Code of Conduct

Absolutely anyone is welcome to submit a comment here. But not all comments will be posted. Think of it like writing a letter to the editor. All submitted comments will be read, but not all published. Published comments will be on-topic, helpful, and further the discussion or debate.

Want to tell us something privately?

Feel free to use our contact form. That's a great place to let us know about typos or anything off-topic.