How to using svg base64 for cms platforms, pdf generators, and legacy apis
- Step 1Confirm the target accepts data: URIs at all — Before encoding, test a tiny
<img src="data:image/svg+xml;base64,...">in the actual legacy field. If the sanitiser strips it, no amount of encoding helps — you'll need an allow-list change or a raster fallback. This one test saves hours. - Step 2Choose the embedding form the system expects — HTML
<img>context → encode with Include data URI prefix on. A raw text/description field that you'll wrap elsewhere → prefix off. Match the form to the field; don't paste a full data URI into a place that adds its own prefix. - Step 3Shrink the SVG before encoding — Legacy fields often cap length (TEXT vs VARCHAR, editor limits). Run svg-metadata-scrubber then svg-pro-minifier first so the Base64 fits. Base64 inflates by ~33%, so a tight source is essential near a field cap.
- Step 4Encode and check the length — Run the SVG through the encoder and note the output character count (the Size overhead metric helps). Compare it against the target field's documented limit before you paste.
- Step 5Paste and save through the platform's own editor — Use the CMS's editor/API, not a direct DB write, so the platform's sanitiser runs the way it will at render time. A string that saves via raw SQL might be stripped when edited through the UI later.
- Step 6Render-test across the platforms you support — Open the saved content in the front-end, in the admin preview, and in any export path (PDF, DOCX, email client). Legacy stacks often render differently in each — verify the SVG appears everywhere it must, with a fallback where it can't.
Legacy-platform Base64 SVG compatibility
How common legacy/enterprise systems treat a Base64 SVG data URI. Behaviour depends on each platform's sanitiser and configuration — always test in your instance.
| Platform / context | Base64 SVG in img src? | Watch out for |
|---|---|---|
| WordPress post content | Usually allowed | WordPress strips inline <svg> markup by default for security, but a Base64 SVG in <img src> is treated as an image, not markup. Full inline SVG needs a plugin allow-list |
| Salesforce email template | Often used to bypass blocked domains | Salesforce blocks external image domains by default; a data: <img> embeds inline. Test in the actual email render, not just the builder preview |
| DOMPurify-sanitised CMS | Stripped by default | DOMPurify removes data: URIs from img src unless ADD_DATA_URI_TAGS / allowed-URI config is set. Not an encoding fault — a policy choice |
| Legacy REST API text field | Stored as text fine | Field length caps (VARCHAR(255) is fatal; use TEXT). Some APIs JSON-escape the value — Base64 has no <> quotes so it escapes cleanly |
| Word / DOCX export (Pandoc, LibreOffice) | Usually embedded correctly | Most converters interpret the data: URI and embed the image. Test your specific toolchain — some rasterise the SVG, some keep it vector |
| Old email client (some Outlook) | May not render SVG at all | Even inlined as Base64, several email clients lack SVG rendering. Keep a PNG fallback; Base64 fixes blocked-domains, not no-SVG-support |
Field-length planning
Base64 expands the source by ~33% (more with the prefix). Plan against the destination field's cap before encoding.
| Source SVG size | Approx. bare Base64 | With data: prefix | Fits in… |
|---|---|---|---|
| 0.5 KB | ~0.7 KB | ~0.7 KB | Most TEXT fields; too big for VARCHAR(255) |
| 2 KB | ~2.7 KB | ~2.7 KB | TEXT / MEDIUMTEXT; many CMS body fields |
| 10 KB | ~13.4 KB | ~13.4 KB | MEDIUMTEXT; watch editor paste limits |
| 50 KB | ~67 KB | ~67 KB | Getting heavy for inline — consider a hosted file if the platform allows it |
Cookbook
How Base64 SVG behaves across real legacy stacks, and how to keep it within their constraints.
WordPress — Base64 img where inline SVG is blocked
WordPress strips inline <svg> from post content by default but accepts an image. Encode with the prefix on and use an img tag; the SVG renders without the markup ever being interpreted as SVG by the sanitiser.
Blocked by default (stripped):
<svg viewBox="0 0 16 16"><path d="…"/></svg>
Works (image, not markup):
<img src="data:image/svg+xml;base64,PHN2ZyB2aWV3…"
width="16" height="16" alt="badge">
Full inline <svg> still needs an SVG-support plugin + allow-list.Salesforce email — dodge the blocked-domain rule
Salesforce blocks external image domains in emails by default, so a hosted SVG won't load. An inline Base64 data URI embeds the mark in the message itself.
Won't load (external domain blocked):
<img src="https://cdn.example.com/logo.svg">
Embeds inline:
<img src="data:image/svg+xml;base64,PHN2ZyB4bWxu…"
width="140" alt="Acme">
Test in the rendered email — the builder preview lies.DOMPurify stripped it — diagnose, don't re-encode
If your CMS uses DOMPurify and the image vanishes, the encoding is fine — the sanitiser removed the data: URI. The fix is configuration, not a different encode.
Symptom: <img> with data:image/svg+xml;base64 disappears on save.
Cause: DOMPurify default config drops data: URIs in img src.
Fix (in the app, not the SVG):
DOMPurify.sanitize(html, {
ADD_DATA_URI_TAGS: ['img'] // or configure ALLOWED_URI_REGEXP
});
Re-encoding the SVG changes nothing — it's a policy block.Legacy API field — store bare Base64, fit the column
An older REST API takes an icon as a text field. Store bare Base64 (prefix off) so the value is a clean string, and make sure the column is TEXT, not VARCHAR(255).
Encode with Include data URI prefix = OFF:
{ "icon_b64": "PHN2ZyB4bWxu…" }
Schema:
icon_b64 TEXT -- not VARCHAR(255): a 2KB SVG ≈ 2.7KB Base64
Client rebuilds:
img.src = 'data:image/svg+xml;base64,' + row.icon_b64;DOCX export — verify the converter keeps it vector
Exporting HTML with a Base64 SVG to DOCX usually embeds the image, but converters differ: some keep it vector, some rasterise. Test your toolchain and minify first to keep the embedded payload small.
Pipeline:
HTML w/ <img src="data:image/svg+xml;base64,…">
│ Pandoc / LibreOffice headless
▼
.docx with embedded image
Check: does the DOCX keep crisp vector, or a blurry raster?
Minify the source first (/svg-tools/svg-pro-minifier) either way.Edge cases and what actually happens
Sanitiser strips the data: URI
Sanitiser blockDOMPurify (default config) and several CMS filters remove data: URIs from img src. The Base64 is valid — the platform's policy rejected the scheme. Fix it in the sanitiser config (allow data: for img), not by re-encoding. If you can't change the policy, fall back to a hosted file or PNG.
WordPress strips inline SVG markup
By designWordPress removes raw <svg>...</svg> from post content by default for security. A Base64 SVG inside <img src> is fine because it's stored and rendered as an image, never parsed as live SVG. If you genuinely need inline <svg> (CSS targeting, animation), you need an SVG-support plugin and an allow-list — Base64 won't unlock that.
Field length cap truncates the string
TruncatedA VARCHAR(255) column or an editor paste limit will silently cut a Base64 SVG mid-string, producing a corrupt, non-rendering value. Plan against the field cap before encoding: use TEXT/MEDIUMTEXT, and minify the source so the ~33%-inflated string fits.
Email client can't render SVG
Client gapSome Outlook versions and webmail clients don't render SVG even when inlined as Base64. The encoding is correct; the client lacks SVG support. Base64 solves the blocked-external-domain problem, not the no-SVG-rendering problem — supply a PNG fallback for those clients.
Untrusted SVG carries a script
Security riskBase64 is encoding, not sanitisation — an SVG with an inline <script> or onload is still dangerous once decoded and rendered as live SVG. In <img src> browsers don't execute it, but inlined into the DOM they may. Never inline untrusted SVG; scrub it first with svg-metadata-scrubber.
Double prefix from mixing forms
Render failPasting a full data:image/svg+xml;base64,... value into a system that prepends its own prefix yields data:...,data:... — the image breaks. Match the encode to the field: prefix on for raw <img src>, prefix off for any field/API that adds the scheme itself.
Saved via raw SQL but stripped through the UI later
Deferred stripA Base64 SVG written directly to the database may render fine until someone edits the record through the CMS UI, at which point the platform's sanitiser strips it. Always save through the platform's own editor/API so you see the sanitiser's real behaviour up front.
Converter rasterises the SVG on export
Quality lossSome DOCX/PDF converters rasterise an embedded SVG instead of keeping it vector, giving you a blurry result at scale. The Base64 was correct; the converter chose to rasterise. Test your specific toolchain, and provide a higher-resolution source or a true vector path where crispness matters.
Frequently asked questions
Will Base64 SVGs survive HTML sanitisation in a CMS?
It depends on the sanitiser config. Most allow <img src> with data: URIs; some security-focused ones (DOMPurify default, certain CMS filters) strip data: by default. Test a tiny Base64 SVG in your actual field first. If it's stripped, change the allowed-URI config — re-encoding won't help, since it's a policy block, not an encoding fault.
How do I use a Base64 SVG in a Salesforce email template?
Encode with the prefix on and use <img src="data:image/svg+xml;base64,...">. Salesforce blocks external image domains by default, so a hosted SVG won't load — the inline data URI embeds the mark in the message. Test in the rendered email (not just the builder preview), and keep a PNG fallback for clients without SVG support.
Does WordPress support Base64 SVG in post content?
Yes, inside an <img src>. WordPress strips raw <svg> markup by default for security, but a Base64 SVG in an image tag isn't interpreted as SVG markup, so it's allowed. If you need true inline <svg> (for animation or CSS), you'll need an SVG-support plugin and an allow-list — Base64 doesn't unlock that path.
What happens to a Base64 SVG when exported to a Word document?
Most HTML-to-DOCX converters (Pandoc, LibreOffice) interpret the data: URI and embed the image. Some keep it vector, some rasterise it. Test your specific toolchain, minify the source first to keep the embedded payload small, and check the output crispness at the size you need.
My CMS field has a length limit — how big can the SVG be?
Plan for ~33% expansion (more with the prefix). A 2 KB SVG becomes ~2.7 KB Base64. Use a TEXT/MEDIUMTEXT column, never VARCHAR(255), and minify the source with svg-pro-minifier and svg-metadata-scrubber first. Check the output length against the field cap before pasting.
Should the prefix be on or off for a legacy system?
On for anything that consumes a complete <img src> directly. Off for a raw text/description field or API that wraps the value itself. Getting this wrong causes a double data: prefix (broken image) or a missing scheme (nothing renders). The tool's single checkbox sets this per encode.
Is Base64 SVG safe to accept from users?
Treat it as untrusted SVG, because that's what it is. Base64 is encoding, not sanitisation — a decoded SVG can still contain <script> or event handlers. In <img src> browsers won't execute it, but inlined into the DOM they may. Scrub untrusted SVG with svg-metadata-scrubber and avoid inlining it as live markup.
Is my artwork uploaded when I encode it here?
No. Encoding runs entirely in your browser — the result panel shows 0 bytes uploaded. For internal logos, customer artwork, or anything you can't send to a third party, that matters: nothing leaves the tab. Only an anonymous usage counter (no content) is recorded for dashboard stats.
Why did my Base64 image disappear after editing the record?
The platform's sanitiser likely ran on save through the UI and stripped the data: URI, even though a direct DB write had kept it. Always save through the CMS editor/API so you see the sanitiser's real behaviour. If it strips data:, change the allowed-URI policy or use a hosted file.
Can I use this for a legacy PDF generator?
Often yes — many PDF generators accept SVG as a Base64 string. Encode (prefix usually on for libraries expecting a data URI) and pass it in. Some libraries want raw SVG markup instead; check the library's input expectation. See the automation guide for batch encoding many marks for a report.
Does the encoder add line breaks that might break a legacy parser?
No. Output is a single unbroken RFC 4648 line — no MIME 76-column wrapping. That's what data: URIs and most modern fields want. A rare legacy MIME/email parser might expect wrapping; if so, wrap the copied string yourself, since the tool won't.
What if the legacy system doesn't support SVG at all?
Then Base64 SVG won't render regardless — the problem is SVG support, not file referencing. Rasterise to PNG and embed that as a fallback. Base64 only solves the can't-reference-an-external-file and blocked-domain problems; it can't add SVG rendering to a system that lacks it.
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.