A complete SVG document encoded to Base64 becomes a single text token of the form data:image/svg+xml;base64,…, where the bytes after the comma are the SVG source expressed as RFC 4648 Base64 characters. Four Base64 characters normally represent three source bytes, so the encoded output is about one third larger than the original SVG before the data URL prefix is added, and Base64 is defined by RFC 4648 as a binary-to-text representation rather than a compression format. The Unicode characters inside the SVG, including attribute values, text nodes, comments, and metadata, must be turned into bytes before Base64 encoding, and the standard contract requires that conversion to be UTF-8 rather than Latin-1 so that accented letters, CJK ideographs, and emoji round-trip correctly. The SVG to Base64 Converter performs this Unicode-to-UTF-8 step with the browser's TextEncoder, processes the byte stream in bounded chunks, applies Base64, then prepends the exact data:image/svg+xml;base64, prefix the decoder expects. None of this renders or executes the SVG, none of it sanitizes active content, and none of it leaves the current browser tab, which makes the conversion predictable to test and safe to run on proprietary icons you already control.
What "encode SVG to Base64" actually produces
The phrase covers one specific transformation: a complete SVG text document becomes a copy-pasteable data URL you can drop into a CSS background-image property, an <img src="…"> attribute, or an HTML inline SVG context. The output is plain text, not an image file, and it is self-contained in the sense that the consumer does not need a second network request to fetch the artwork. That self-containment is the reason developers reach for it: it removes an HTTP round trip, lets a stylesheet ship as a single file, and avoids broken images when a page is opened from the file system. The trade-off is that the encoded payload rides along with every page or stylesheet that contains it, the browser cannot cache the SVG independently, and the bytes are larger than the original markup. Encoding is also entirely agnostic to what the SVG draws. Whether the document contains a single black square or a script tag that reads cookies, the converter emits the same kind of data URL, and the security responsibility stays with whoever decides how the result is embedded.
How to encode SVG to Base64 in three steps
- Open the SVG to Base64 Converter, choose Encode, and paste the complete SVG source. A complete source has an <svg> root and a closing </svg> tag after an optional byte-order mark and surrounding whitespace are trimmed.
- Run the conversion and inspect the full text result in the output area. The result begins with data:image/svg+xml;base64, followed by Base64 characters with no embedded scripts, fetches, or rendering involved.
- Copy the result and test it in the exact trusted destination. Paste it into a CSS rule, an <img> tag, or a sandboxed HTML preview, then confirm the destination's size limits and content security policy accept the payload before you commit it.
Why Unicode characters need a UTF-8 step first
A JavaScript string is a sequence of UTF-16 code units, not bytes, and Base64 operates on bytes. The naive shortcut of calling btoa(svgString) works only when the string contains characters that happen to share their code point values with ASCII, which is why ASCII-only icons often seem to encode fine and why a single accented letter, Chinese character, or emoji silently corrupts the output. According to the WHATWG Encoding Standard, the correct pipeline converts the string to UTF-8 bytes first, which turns one ASCII character into one byte, one two-byte sequence such as é into two bytes, one three-byte sequence into three bytes, and one emoji into four bytes. The SVG to Base64 Converter uses TextEncoder for that conversion and then Base64-encodes the resulting byte array in chunks to avoid an oversized argument list on the encoding call. On the decode side, malformed UTF-8 raises an error instead of substituting the U+FFFD replacement character, which is what makes a falsely successful round trip impossible: a broken document fails loudly rather than rendering with silently swapped glyphs.
Inline data URL versus a separate SVG file
The same SVG can travel into the browser as an inline data URL or as a separately referenced file, and the right answer depends on size, reuse, and caching. The table below summarizes the documented trade-offs without claiming a universal winner, because the delivered numbers depend on the rest of your page and your server's content negotiation.
| Consideration | Inline data URL | Separate .svg file |
|---|---|---|
| HTTP requests needed | One fewer fetch, since the artwork rides in HTML or CSS | One additional request for the artwork |
| HTTP caching | Tied to the parent document; cannot be cached independently | Reused across pages and visits with normal cache headers |
| Effect of Base64 expansion | Inline payload grows by about one third, plus the prefix | File served as image/svg+xml; HTTP content encoding can compress it |
| Debugging in DevTools | Encoded string is hard to inspect and edit live | Source SVG opens directly as text |
| Best fit | Small, unique icons bundled once | Reused assets, large artwork, frequently updated graphics |
For a reused logo or a glyph set shared across many pages, a separately cached SVG file usually wins on bytes delivered. For a one-off icon that only appears inside a single CSS bundle, an inline data URL can simplify deployment. Measure with the real page rather than the icon alone.
Round-tripping the data URL with the decoder
The fastest way to confirm an encoder produced exactly the bytes you expected is to decode the result back to text and diff it against the source. The same tool accepts the data:image/svg+xml;base64, prefix as its only recognized input, which is a deliberate narrow contract: it rejects plain Base64 without a media type, URL-encoded SVG, alternate media type parameters, and whitespace-normalized payloads. That contract keeps the round trip deterministic, so when the decoder returns the original Unicode document you know the encoder neither dropped characters nor silently substituted bytes. A practical pattern is to encode the SVG, paste the data URL into the decoder, copy the recovered text into a tool such as the Diff Checker, and confirm the only difference is optional whitespace. If you encode the SVG to embed it in CSS, round-trip once with a tiny sample document first so the data URL length is predictable before you wire it into a build step or a content security policy.
Security boundaries the encoder does not cross
Encoding is not sanitization. SVG can carry scripts, event handlers such as onload, foreign content via <foreignObject>, links, external image references, CSS animations that fetch resources, and filter primitives whose behavior depends on the embedding context. The converter never previews the supplied SVG and never rewrites it, which is a security boundary rather than a gap: rendering inside the tool would require a sandbox designed for that purpose, and the contract deliberately avoids the complexity. A syntactically accepted string can still be invalid SVG, render differently across browsers, or point at resources that are not available, and namespaces, attributes, references, dimensions, paths, styles, and accessibility metadata are not repaired. Encoding also does not change how the destination treats the payload. Place the data URL only into contexts you control, respect the consumer's content security policy, and route any untrusted SVG through a maintained sanitization pipeline before it reaches the encoder. The 500,000-character source limit bounds memory and main-thread work, but the resulting data URL can still exceed limits in browsers, databases, headers, QR codes, or build tools, so check those budgets with the real destination rather than the source length alone. Eight RFC 4648 and UTF-8 fixtures lock the encoder's output for ASCII markup, two-, three-, and four-byte UTF-8 sequences, attributes, newlines, nested markup, and namespace text, and additional tests reject malformed documents, wrong prefixes, and invalid Base64, which is why a successful round trip is a meaningful signal rather than a hopeful guess.