Turn an SVG into a data URI
An SVG becomes a data URI by percent-encoding the handful of characters a URL cannot carry and putting what is left after data:image/svg+xml. Paste the markup above and two lines come back: the bare URI for the src of an img tag, and the whole background-image declaration for a stylesheet. The picture then travels inside the file that uses it, so the browser never makes a second request to go and fetch it.
Turn an SVG into a data URI
Paste an SVG and get the line you can put straight into a stylesheet, or into the src of an img tag. The file is read and encoded by this tab, on your own machine, so the markup you paste is not uploaded anywhere.
SVG to data URI, step by step
- Paste the SVGDrop the markup into the box, or choose the file and it is read here on your own machine rather than sent anywhere for encoding.
- Take the shape you needThe bare URI goes in the src of an img tag. The declaration below it goes in a stylesheet, quoted so the double quotes in the markup survive the trip.
- Copy itOne press puts it on the clipboard, which is where it is going, into a file you already have open. There is a download beside it if you would rather have one.
Why this percent-encodes the URL rather than reaching for base64
Both forms work and only one of them is a good idea. Base64 turns every three bytes into four, so the same picture costs about a third more, and what lands in your stylesheet is an unbroken run of letters nobody is ever going to read. Percent-encoding touches only the characters a URL genuinely cannot carry: the percent sign itself, the hash that would otherwise end the URL, the angle brackets, both kinds of quote, and the whitespace. Every other byte is left exactly as it was written, so in a year you can still search the stylesheet for a shape id and find out which file that logo came from. The single quotes around the CSS url() are the other half of the same decision, because the markup inside is full of double quotes and they have to survive.
There are two reasons to inline a picture and only one of them is about speed. The first is the obvious one: a data URI is already in the file the browser is reading, so there is no second request, no extra connection and no chance of the icon arriving a beat after everything else and shifting the layout as it lands.
The second is that it stops being a file you can lose. A logo that lives at /img/logo.svg is one
tidy-up away from being a broken image on a page nobody checked. A logo that lives inside the
stylesheet moves with the stylesheet, and it either works everywhere the stylesheet works or it
works nowhere, which is a much easier thing to notice.
The catch is that it is a copy. Every stylesheet carrying it carries the whole picture, and every page that loads that stylesheet downloads it again with no way to cache it separately. That is fine for the twenty small marks in your interface and it is silly for the illustration on the homepage, which is the whole of the rule: inline it while it is measured in hundreds of bytes, and keep it as a file once it is measured in kilobytes. The panel shows both sizes so you can see which of those you are looking at.
Questions
Should I inline the picture or keep it as a separate file?
Inline it while it is small. An icon of a few hundred bytes costs less sitting in the stylesheet than the round trip to go and fetch it does. Keep the file once it is big, because a data URI cannot be cached on its own, so it is re-sent with every copy of the page or stylesheet that carries it.
Why does my picture come out the wrong size?
Almost always a missing viewBox. A file with no intrinsic size at all is drawn at 300 by 150 by every browser there is and then stretched to fit whatever box it landed in. The panel says so when your file has that problem, and the fix is a viewBox in your drawing app rather than anything here.
Does the text inside my SVG still use my web font?
No, and this catches people out. A data URI is drawn as a picture, in a document of its own, and that document loads no web fonts whatsoever. The letters come out in whichever substitute the machine has and the spacing moves with them. Convert the text to outlines before you encode it.
Is the markup I paste uploaded anywhere?
The markup is not. It is read and encoded by code running in this tab, on your own machine, and the answer goes to your clipboard. The page does record that a conversion happened, in the same way it records that you opened it, and that record carries nothing about your file, so no name, no size and none of its contents.
Can I put the result in an inline style attribute?
Yes, and it is the one spot worth being careful about. An inline style attribute is already wrapped in double quotes in your HTML, so use the CSS line exactly as it comes, single quotes and all, rather than swapping the two round out of habit.
Other things here
There is a full list on the free tools page. They all work the same way: in the browser, with nothing to install.
The tool is free. So is the thought.
This page did one small job. Edmund is for the thing you thought of while doing it: a capture app for iPhone, iPad and Mac that files a note the moment you have it, so it does not get lost between having it and writing it down.
See what Edmund does