Base64 turns a complete SVG document into a data:image/svg+xml;base64 string so the vector file can live inside HTML, CSS, or JavaScript without a separate HTTP request. The conversion is a pure text-to-text operation defined by RFC 4648: every three bytes of the source SVG become four Base64 characters, so the encoded output is roughly one third larger than the original before the data URL prefix is added. Unicode characters, accented Latin, CJK glyphs, and emoji are first encoded as UTF-8 bytes, then those bytes are Base64-encoded. The full reversible path is SVG source to UTF-8 bytes to Base64 characters to data URL. The reverse direction takes a matching data URL, strips the prefix, decodes the Base64, and validates the bytes as UTF-8 before returning the SVG text. The SVG to Base64 Converter does exactly this conversion in your browser, with no upload, no rendering, and no silent sanitization of the source document.
The Anatomy of an SVG Data URL
A data URL is a single line of text that includes a media type, an encoding label, and the base payload. For an SVG, the standardized form is data:image/svg+xml;base64,<payload>, where the prefix tells the consumer what kind of bytes follow and how they were produced. The payload is the Base64-encoded UTF-8 byte sequence of the SVG, and the prefix itself is not part of the encoded bytes; the decoder strips it before reversing the encoding. Per RFC 4648, Base64 is a binary-to-text alphabet, not a compression format, so the payload is always larger than the original byte length.
A few practical implications follow from this structure:
- The same prefix is required on both sides of the round trip. A missing, mistyped, or alternate prefix is rejected by a strict decoder rather than silently producing a wrong result.
- The payload is opaque ASCII. The original SVG markup is not human-readable inside the data URL and cannot be diffed in a code review without decoding.
- The data URL is a single string with no references to external files, so anything the SVG needs (fonts, images, scripts) must be inlined or reachable from the embedding context.
How to Convert an SVG to Base64
- Open the SVG to Base64 Converter in your browser. Choose the Encode direction.
- Paste a complete SVG document into the source area. The tool requires a complete svg root element with a closing tag, after trimming an optional UTF-8 byte-order mark and surrounding whitespace. It does not require a specific namespace declaration, but namespaces, attributes, and element content you supply are preserved as-is.
- Run the conversion. The tool encodes the Unicode text as UTF-8 bytes with the browser's TextEncoder, processes those bytes in bounded chunks, and Base64-encodes the chunks into a single output string.
- Inspect the full text result. The returned string begins with the exact prefix data:image/svg+xml;base64, followed by the Base64 payload. Verify the first characters of the payload match a known round-trip test if you need confidence that the encoding is correct.
- Copy the complete data URL. Paste it into the exact destination where it will be used: an img src, a CSS background-image: url(...) declaration, a JavaScript string, or a build-time template.
- Test the rendered result in the real consumer before shipping. Open the page or preview, confirm the SVG renders, and check the browser console for CSP or mixed-content errors.
The source input is bounded at 500,000 characters. The resulting data URL can still exceed that target site policy, header size, or any smaller size budget your destination imposes, so plan the test step before you commit to inline embedding.
Reading the Encoded Output Back
The reverse direction is useful when you have inherited a data URL from a build tool, a CMS export, or a stylesheet and want to recover the original SVG to edit it. The converter handles this with the same three-step shape, choosing the Decode direction instead of Encode.
| Direction | Input | Output | Validation step |
|---|---|---|---|
| Encode | Complete SVG document (UTF-8 text) | data:image/svg+xml;base64,... string | Trim BOM, verify svg root structure |
| Decode | Exact data:image/svg+xml;base64,... string | UTF-8 SVG text | Fatal UTF-8 validation on decoded bytes |
The decoder only accepts the exact prefix. It does not guess plain Base64, URL-encoded SVG, alternate media type parameters, or whitespace-normalized payloads. A narrow input contract prevents accidental decoding of unrelated data and keeps round-trip behavior deterministic across browsers. If the input does not match, the converter returns an error rather than trying to repair the prefix or substituting replacement characters.
Why the Encoded Output Is Larger Than the Source
Base64 allocates one ASCII character for every six bits of source data. Three source bytes (24 bits) become four Base64 characters, which is the rule that drives the size growth. For a small SVG, the math is straightforward.
A 300-byte SVG produces 300 / 3 * 4 = 400 Base64 characters, plus the 26-character data:image/svg+xml;base64, prefix, giving roughly 426 characters total. That is about 42% larger than the source bytes, not including any padding = characters the algorithm adds when the input length is not divisible by three.
This expansion is not a bug. Base64 is documented as a binary-to-text representation that is not compression, and the WHATWG encoding standard defines the UTF-8 byte sequence that Base64 consumes. The growth is the price of moving binary data through text-only channels. Two practical consequences for SVG specifically:
- An SVG served as a separate file can be compressed with HTTP content encoding (typically gzip or Brotli). The same SVG inlined as a Base64 data URL is usually served uncompressed, so the wire size grows even more than the Base64 expansion alone suggests.
- The data URL cannot be cached independently from the host document. If the same SVG appears in multiple pages, every page ships its own copy.
The reliable heuristic is to measure the delivered HTML, CSS, or JavaScript size with the data URL included, not to assume inline is faster. For larger reusable assets, a separately cached SVG file almost always wins.
Unicode, UTF-8, and Special Characters
SVG documents frequently contain non-ASCII characters: accented Latin text inside text elements, CJK labels, emoji, or comments. These must be encoded as UTF-8 bytes before they are Base64-encoded. A common failure mode is to take a JavaScript string and pass it directly to a Latin-1-only Base64 helper, which silently corrupts codepoints above 255 because each character is treated as one byte.
The converter uses the browser's TextEncoder to produce a UTF-8 byte sequence, processes the bytes in bounded chunks to avoid an oversized argument list, and then applies Base64. On the decode side, the byte sequence is run through a fatal UTF-8 validator. Malformed UTF-8 produces an explicit error rather than the replacement character U+FFFD, which would create a falsely successful round trip that still looked clean.
| Source text | UTF-8 byte count | Base64 character count |
|---|---|---|
| ASCII only (e.g. simple markup) | 1 byte per character | 4 characters per 3 bytes |
| Accented Latin (e.g. é) | 2 bytes per character | 4 characters per 3 bytes |
| CJK and most emoji | 3 or 4 bytes per character | 4 characters per 3 bytes |
The byte-to-character ratio is fixed by Base64 itself; the source character types only change how many bytes the source text expands to before Base64 encoding begins. With UTF-8 byte output specified by the encoding standard, the same one-third formula applies once you have the byte count.
Where Data URLs Fit Best (and When to Skip Them)
Base64 SVG data URLs are useful when the vector is small, single-purpose, and tied to a specific document. Common fits include inline icons and logos inside a single page or template, where an extra HTTP request would be more expensive than the size growth; email templates, where many clients block external images and the data URL travels with the message; server-rendered HTML where the SVG is built from user-controlled data and the data URL is the simplest way to inject the result; and CSS demos and CodePen-style snippets where readability of the source matters less than drop-in paste.
Skip inlining when the SVG is large, reused across many pages, or part of a design system. A separate file with proper HTTP caching, content encoding, and a stable URL is almost always cheaper to ship and easier to debug. The 500,000-character source limit in the converter also implies a ceiling on the data URL you can produce; if your deliverable exceeds that, the file path is the right one.
Security: What Base64 Does and Does Not Do
Base64 is a presentation format, not a security boundary. Encoding an SVG does not sanitize it, does not strip scripts, and does not block external resources. Scripts, event handlers, foreignObject content, links, external font references, and filter primitives all remain inside the data URL and become active again as soon as the result is embedded in a context that runs them.
The converter never previews or executes the supplied SVG, which removes the immediate risk of accidental execution during the conversion step. The risk transfers to the embedding site. Concretely, do not place untrusted SVG output into an iframe, object, the DOM, or a CSS property without a maintained sanitization pipeline and a content security policy designed for that context. Treat the data URL as you would treat the original SVG file: if you would not host the file on your site, do not embed the data URL either. Use a separate, sandboxed serving context for untrusted SVG, with strict headers and a maintained sanitizer. Encoding alone provides no protection.
Testing the Result in the Real Destination
The conversion is local, but the property that matters is what the destination actually does with the data URL. Before shipping, confirm three things.
- The destination's content security policy allows the data URL. Some sites block data: scheme URLs in CSS, in inline scripts, or in image contexts entirely. img-src 'self' data: is the common-case value that permits inline SVG images.
- The destination's size budget is not exceeded. Headers, database columns, QR codes, and template engines all have limits the 500,000-character source limit does not preempt.
- The SVG renders the same way in the embedding context as it does as a standalone file. A sanitized Markdown renderer, a strict CSS parser, or a stripped-down mail client may react differently to scripts, filters, or external references than a full browser would.
If the rendered result diverges, the source SVG is the thing to inspect, not the data URL. The encoding is deterministic and reversible; differences come from the embedding context, not from the conversion.