Decode a Base64-encoded SVG to view the vector graphic and download as .svg. Also generates a data URI you can paste directly into CSS or HTML.
SVG is a text-based XML format, so it survives Base64 encoding identically to any other file. For SVG specifically, you can often skip Base64 entirely and use URL-encoding (data:image/svg+xml;utf8,<svg…>) — the result is smaller because text doesn’t inflate the way Base64 does.
SVG is text-based (XML), so it does not benefit from Base64 the way binary formats do. URL-encoding SVG produces a smaller data URI than Base64 encoding does. The form "data:image/svg+xml;utf8,..." is typically 25–30% smaller than the equivalent "data:image/svg+xml;base64,..." form.
Yes — Base64 is lossless. The decoded bytes are byte-for-byte identical to the original SVG source. If the SVG referenced external fonts or images, those still need to be available; Base64 does not embed them.
Yes. Once decoded back to plain text, the SVG is just XML that you can edit in any text editor. Use the "Download" button to save it as a .svg file.
SVG is unique among image formats: it is plain text (XML), not binary. Base64 is designed to safely move binary data through text-only channels — but SVG is already text. Encoding it as Base64 inflates the file by 33% and adds no real benefit. For inline use in CSS or HTML, URL-encoding the SVG produces a smaller, more efficient data URI than Base64 does.
For example, a 200-byte SVG icon becomes about 270 characters as URL-encoded (data:image/svg+xml;utf8,%3Csvg%20...%3C/svg%3E) but about 300 characters as Base64 (data:image/svg+xml;base64,PHN2Z...). The savings compound for larger SVGs. Most modern CSS minifiers automatically use URL-encoding for SVG data URIs when they detect inline SVG.
Despite the inefficiency, you will encounter Base64-encoded SVGs in real systems. The pattern is common in: legacy build tools that handle all image formats uniformly through Base64, email clients that strip URL-encoding but accept Base64, WYSIWYG editors that copy-paste images regardless of format, and API responses that return arbitrary image bytes already Base64-encoded for binary-safe transport.
Our tool decodes the Base64 back to the original SVG XML so you can inspect, edit, or re-export it in a more efficient form. The decoded SVG is text — you can read it directly, copy it into an editor, or paste it inline in an HTML page.
Unlike binary formats, SVG has no magic bytes — it is just an XML document. We identify it by looking at the first non-whitespace bytes after decoding. Valid SVG always starts with one of: <svg (direct SVG element), <?xml followed by an XML declaration leading to <svg, or <!DOCTYPE svg (older DOCTYPE form). If the decoded text does not start with one of these patterns, the data is not valid SVG.
One common pitfall: developers sometimes confuse SVG with HTML or generic XML. SVG must have the xmlns="http://www.w3.org/2000/svg" attribute on its root element to render correctly in browsers — without it, the browser parses the markup as generic XML and shows nothing.
Once decoded, the SVG is plain text that you can paste anywhere XML is accepted. Inline in HTML: paste the SVG directly into your markup — no img tag needed, and CSS can style it. As a CSS background: URL-encode the SVG (do not re-Base64 it) and use background-image: url("data:image/svg+xml;utf8,..."). As an external file: download the .svg and reference it normally from an img tag or background-image.
For animation or interactivity, inline SVG is the only option — neither data URIs nor external .svg files allow JavaScript to manipulate the SVG's individual elements. If you need to animate paths or make icons clickable, inline the SVG directly into your HTML.