How to convert svg files to base64 encoded strings instantly
- Step 1Drop a .svg file or paste the source — Click the drop zone to browse, drag a
.svgonto it, or paste raw SVG markup into the Or paste SVG source code textarea below it. Pasted markup is validated with a real DOM parse — if the root element isn't<svg>or the XML is malformed, you getInvalid SVGbefore any encoding runs. This is a single-file tool, so only the first dropped file is used. - Step 2Decide whether you need the data URI prefix — Leave Include data URI prefix on if the string is going into an
img src, a CSSurl(...), or a React NativeImagesource — you'll getdata:image/svg+xml;base64,<encoded>. Turn it off when the target is a JSON value, a database column, or anything that adds the prefix itself, so you store only the raw Base64. - Step 3Click Process SVG — Press Process SVG. Encoding is synchronous and instant for typical icon-sized files. If the input exceeds your tier's per-job limit (5 MB free, 50 MB Pro), the run is blocked with an explicit size message instead of silently truncating.
- Step 4Read the Size overhead metric — The result panel shows Size overhead as
+N%. This is computed against your input bytes and includes the prefix when it's on, so a tiny icon with the prefix can read higher than 33% — the fixed prefix string is a larger share of a small payload. - Step 5Copy or download the string — Click Copy to clipboard for the full string (the on-screen preview truncates long output at 2,000 characters, but copy and download always include the whole thing), or Download TXT to save
<name>-base64.txt. - Step 6Paste it into the target context — With the prefix on:
<img src="data:image/svg+xml;base64,...">orbackground-image: url('data:image/svg+xml;base64,...'). With it off: drop the raw string into your JSON field. To go back the other way, paste the string into a browser console asatob(s)— this tool only encodes.
The single option, and what each setting emits
The web UI exposes exactly one control — a checkbox. There is no separate raw/MIME/line-break setting.
| Setting | Output shape | Use it for |
|---|---|---|
| Include data URI prefix = on (default) | data:image/svg+xml;base64,PHN2ZyB4bWxucz0i… | img src, CSS background-image: url(...), React Native Image source, <link rel="icon"> |
| Include data URI prefix = off | PHN2ZyB4bWxucz0i… (bare RFC 4648 Base64, no prefix, no line breaks) | JSON / API response fields, database columns, PDF-library image args, anywhere the consumer adds its own prefix |
What this tool does and does not do
Verified against the implementation. If a capability is listed as not supported, the linked sibling tool covers it.
| Capability | Supported? | Detail / where to go instead |
|---|---|---|
| Standard RFC 4648 Base64 encode | Yes | btoa(unescape(encodeURIComponent(svg))) — identical output to a server-side base64 encoder |
| UTF-8 / non-ASCII content | Yes | The encodeURIComponent step converts wide characters before btoa, so accented text and CJK glyphs encode correctly |
| Decode Base64 back to SVG | No | There is no decode tab. Use atob(string) in a browser console, or strip the data:..., prefix first |
| MIME line breaks (76-col) | No | Output is a single unbroken line. If a legacy mail system needs wrapping, wrap it yourself |
| URL-encoded (percent) data URI | No | Use svg-css-data-uri — percent-encoding is smaller than Base64 for CSS backgrounds |
| Batch / multi-file upload | No | The web UI is single-file. For many files, script it with Buffer.from(...).toString('base64') — see batch-svg-base64-encoding-automation |
| Minify before encoding | No | Encoding is verbatim. Shrink first with svg-pro-minifier — every byte saved is ~1.33 fewer Base64 bytes |
Cookbook
Real inputs and the exact string this tool emits. The encoded values below are shortened with … for readability; the tool always returns the full string.
Tiny icon, prefix on — paste straight into an img tag
The default flow. A small inline icon, prefix left on, dropped directly into an HTML img src. Notice the prefix is a fixed 26-character string — on a tiny SVG it inflates the overhead metric well past 33%.
Input (icon.svg, 84 bytes): <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16"><circle cx="8" cy="8" r="7"/></svg> Output (Include data URI prefix = ON): data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmci… Paste: <img src="data:image/svg+xml;base64,PHN2ZyB4bWxu…" width="16" height="16" alt="">
Same icon, prefix off — for a JSON API field
Turn the checkbox off when the string is going into JSON. The consumer (or the framework rendering it) adds the prefix, so you store only the raw bytes and avoid duplicating the data: scheme inside your payload.
Input: icon.svg (same 84 bytes)
Output (Include data URI prefix = OFF):
PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmci…
In the response body:
{
"id": "check",
"svg": "PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmci…"
}
Client rebuilds the URI:
const uri = `data:image/svg+xml;base64,${row.svg}`;SVG with non-ASCII text encodes cleanly
Because the tool runs encodeURIComponent before btoa, multi-byte characters in a <text> element are encoded as their UTF-8 bytes. A naive btoa(svg) would throw on these characters; this tool does not.
Input (label.svg):
<svg xmlns="http://www.w3.org/2000/svg" width="120" height="24">
<text x="4" y="18" font-size="16">Café — 北京</text>
</svg>
Output (prefix off): PHN2ZyB4bWxucz0i…w5YyDljJfkuqw…
Verify in a console:
atob("PHN2ZyB4bWxucz0i…") → the original markup, é and 北京 intactWhy the overhead metric reads above 33% on small files
Base64 itself is ~33% overhead. But the data URI prefix is a constant 26-byte string. On a small icon that constant is a big fraction of the total, so the tool's Size overhead metric (which includes the prefix when on) reads higher than the pure encoding overhead.
84-byte SVG, prefix ON: base64 of 84 bytes ≈ 112 bytes + "data:image/svg+xml;base64," (26 bytes) = 138 bytes output Size overhead = 138/84 − 1 ≈ +64% Same 84-byte SVG, prefix OFF: output ≈ 112 bytes Size overhead = 112/84 − 1 ≈ +33% Takeaway: for many small icons, the prefix cost dominates.
Decoding back to SVG (no decode tab — use the console)
This tool only encodes. To recover the original SVG from a Base64 string, strip the data: prefix if present and run atob in any browser console or Node REPL. The output is the verbatim markup you started with.
// In a browser console:
const s = "data:image/svg+xml;base64,PHN2ZyB4bWxucz0i…";
const b64 = s.replace(/^data:[^,]+,/, ""); // strip any prefix
const svg = atob(b64); // → "<svg …>…</svg>"
// Node:
Buffer.from(b64, "base64").toString("utf-8");Edge cases and what actually happens
Pasted content isn't valid SVG XML
Invalid SVGBefore encoding, pasted text is parsed with the browser's DOM parser. If the root element isn't <svg> or the markup contains a parser error (unclosed tag, stray &), the tool throws Invalid SVG — could not parse the pasted content as valid SVG XML and never produces a string. Dropping a .svg file skips this paste-time check, so a malformed file can still encode — encode is byte-faithful, it does not lint.
Expecting a Decode tab
Not supportedThis is an encoder only — there is no decode mode in the UI. To reverse a string, strip any data:..., prefix and run atob() in a console or Buffer.from(s, 'base64') in Node. The earlier version of this guide referenced a Decode tab that does not exist in the tool.
File larger than the tier limit
RejectedThe client checks file size before encoding: 5 MB on free, 50 MB on Pro, 2 GB on Developer. Over the limit, the run is blocked with File "…" exceeds the … tier per-job limit rather than encoding a truncated string. A 5 MB SVG is already enormous for vector art — if you're near the cap, minify with svg-pro-minifier first.
On-screen preview looks cut off
By designThe result <pre> truncates the preview at 2,000 characters and appends … (truncated — download for full output). This is display-only. Copy to clipboard and Download TXT always contain the complete, untruncated Base64 string. Don't copy from the preview pane by hand for long output.
Output has no line breaks; a legacy reader wants them
Single lineOutput is one unbroken line of Base64 (RFC 4648, not MIME). Modern data: URIs and JSON require exactly this. A rare legacy MIME/email parser may expect 76-column wrapping — the tool does not add it; wrap the string yourself if a downstream system truly requires it.
Using a Base64 SVG where percent-encoding would be smaller
SuboptimalFor CSS background-image, a percent-encoded (URL-encoded) SVG data URI is typically smaller than Base64 because SVG is mostly ASCII that encodes to itself. Base64 expands every 3 bytes to 4 uniformly. If the target is CSS, prefer svg-css-data-uri; reach for Base64 for JSON, React Native, and PDF libraries.
A sanitiser strips your data: URI
Sanitiser-dependentSome HTML sanitisers (DOMPurify with default config, certain CMS filters) strip data: URIs from img src. The encoded string is valid; the platform rejected the scheme. Check the platform's allowed-protocol list — this is policy, not an encoding fault. See svg-base64-legacy-system-integration.
Dropping multiple files at once
First file onlyThe web UI is single-file for this tool — only svg-sprite-builder accepts multiple files. Drop several and only the first is encoded. To batch-encode a folder, use the Node one-liner or runner workflow in batch-svg-base64-encoding-automation.
Comments and metadata are encoded too
VerbatimEncoding is byte-faithful: editor comments, <metadata>, <title>, and Illustrator/Inkscape cruft all become Base64 weight. To drop them before encoding, run svg-metadata-scrubber then svg-pro-minifier first.
Frequently asked questions
What exactly does the tool run under the hood?
In the browser it computes btoa(unescape(encodeURIComponent(svg))). The encodeURIComponent/unescape pair converts the SVG to its UTF-8 byte stream first so btoa (which only handles Latin-1) doesn't choke on non-ASCII characters. The result is standard RFC 4648 Base64 with no line breaks — byte-for-byte identical to what a server-side Buffer.from(svg).toString('base64') produces.
What does the 'Include data URI prefix' checkbox control?
It toggles whether the output starts with data:image/svg+xml;base64,. On (default) gives you a paste-ready value for img src / CSS / React Native. Off gives you the bare Base64 — what you want inside a JSON field or database column where the consumer adds its own prefix. It's the only option this tool exposes.
Can I decode a Base64 string back to SVG here?
No — this tool only encodes; there is no decode tab. To reverse a string, strip any leading data:..., and run atob(b64) in a browser console, or Buffer.from(b64, 'base64').toString('utf-8') in Node. The output is your original markup verbatim.
Does Base64 increase the file size?
Yes — Base64 encodes 3 bytes as 4 ASCII characters, a fixed ~33% increase. With the prefix on, the constant 26-byte data:image/svg+xml;base64, string adds more, which is why the tool's Size overhead metric reads higher than 33% on small icons. For CSS, percent-encoding via svg-css-data-uri is usually smaller.
Why does my overhead metric say +60% instead of +33%?
Because the metric includes the data URI prefix when the checkbox is on, and the prefix is a fixed 26 bytes. On a small icon that constant is a large share of the total. Turn the prefix off and the metric drops back toward the textbook +33%. The Base64 algorithm itself never exceeds ~33%; the rest is the prefix.
Is there a size limit?
The free tier caps input at 5 MB per job, Pro at 50 MB, Developer at 2 GB. The output is ~33% larger than the input. 5 MB is already huge for an SVG, so most users never approach it — if you do, minify the source first with svg-pro-minifier.
Does it produce line breaks like classic MIME Base64?
No. Output is a single unbroken line (RFC 4648), which is exactly what data: URIs and JSON require. There is no 76-column / MIME-wrap option. If some legacy mail parser genuinely needs wrapping, wrap the string yourself after copying it.
Will non-ASCII text in my SVG encode correctly?
Yes. The encodeURIComponent step converts wide characters to UTF-8 bytes before btoa, so <text> content with accents, arrows, emoji, or CJK glyphs round-trips correctly. A plain btoa(svg) would throw on those characters; this tool handles them.
Is my SVG uploaded anywhere?
No. Encoding happens entirely in your browser tab — the result panel shows a 0 bytes uploaded badge. Only a single anonymous usage counter (no content) is recorded for signed-in dashboard stats, and you can opt out in account settings.
Can I encode many SVGs at once?
Not in the web UI — it processes one file at a time (only the sprite builder is multi-file). For folders, use Buffer.from(fs.readFileSync(f)).toString('base64') in Node, or pair the @jadapps/runner and POST to 127.0.0.1:9789/v1/tools/svg-to-base64/run. The batch automation guide has full scripts.
When should I use a plain URL or external file instead of Base64?
When the SVG is reused across pages or you want browser caching. A Base64 (or any data URI) is inlined and can't be cached independently. Base64 shines where you can't reference a file at all — JSON APIs, email HTML, React Native, PDF generation. For shared icons, an external .svg with cache headers wins.
What's the difference between this and the CSS Data URI tool?
svg-css-data-uri emits a percent-encoded (URL-encoded) data URI tuned for CSS background-image, which is typically smaller for SVG than Base64. This tool emits Base64, which is the right choice for JSON fields, React Native Image sources, and PDF libraries that specifically want Base64.
Privacy first
Every JAD SVG tool runs entirely in your browser using the DOM API and Canvas. Your SVG files never leave your device — verified by zero outbound network requests during processing.