Base64 to Image Decoder Online — RFC 4648 + RFC 2397 via window.atob with SVG XSS hardening

Base64 to Image Decoder — RFC 4648 + RFC 2397 via window.atob with SVG XSS hardening

Decode any Base64 ASCII payload or complete data URI back to a downloadable binary image file per RFC 4648 (Simon Josefsson, IETF October 2006 Standards Track) and RFC 2397 (Larry Masinter, Xerox Corporation, IETF August 1998 Standards Track). The decoder runs in your browser via window.atob() (WHATWG HTML Living Standard, html.spec.whatwg.org/multipage/webappapis.html, defined in Web IDL on the WindowOrWorkerGlobalScope mixin) which reverses Base64's 4-ASCII-to-3-byte expansion to recover the original binary bytes. The tool auto-detects the MIME from a data URI prefix via the regular expression `^data:(image/\w+);base64,` and strips it before calling atob; if no prefix is present, the payload is decoded as raw Base64 and treated as image/png by default. The decoded bytes flow through a Uint8Array buffer (via charCodeAt over the atob output string per WHATWG ArrayBuffer + TypedArray spec) into a Blob, then a URL.createObjectURL() blob URL is generated for the preview pane and download button. SECURITY HARDENING: the tool explicitly REJECTS image/svg+xml even though it's a valid image MIME — SVG documents can contain `<script>` elements and inline event-handler attributes (onload, onclick, onerror), and rendering an SVG through a blob URL executes those scripts in the SAME-ORIGIN context of openimages.app, identical to opening a raw HTML file. This SVG-via-blob-URL XSS class has a disclosed advisory of record (CVE-2022-24833 / GHSA-cqcc-mm6x-vmvw, PrivateBin SVG-attachment preview blob URL, April 2022) and recurs as a pattern across user-upload XSS write-ups (research.securitum.com Bentkowski 2019, Angular `DomSanitizer.bypassSecurityTrustResourceUrl` antipattern documented in angular.dev/best-practices/security). The block is intentional defence-in-depth — convert SVG sources via a server-side renderer, not a browser blob URL.

How to decode Base64 to a downloadable image file

Copy the Base64 string OR the full `data:image/<mime>;base64,...` URI from your source (CSS, JSON API payload, email template, configuration file, debug log).
Paste the value into the input textarea. Both forms work: the regex `^data:(image/\w+);base64,` auto-detects the MIME and strips the prefix; raw Base64 without a prefix is decoded as image/png by default.
The tool calls window.atob() per WHATWG to reverse the Base64 expansion (4 ASCII characters → 3 bytes), then builds a Uint8Array and wraps it in a Blob with the detected MIME.
A blob URL is generated via URL.createObjectURL() and shown in the preview pane. If the detected MIME is image/svg+xml, decoding halts with an error — SVG would execute embedded scripts in the page's origin (see security notes).
Click Download to save the decoded bytes as a real binary file with the correct extension (.png, .jpg, .gif, .webp, .avif). The original Base64 string is reconstructed byte-identical — Base64 is a lossless text encoding.

Common use cases

Recovering a real PNG/JPG/WebP from a `data:image/...;base64,...` string copied out of CSS, a JSON API response, an email template, or a saved-state snapshot.
Inspecting what an inline tracking pixel, encoded favicon, or signature image actually contains before trusting or shipping it.
Debugging API responses that return images as Base64 strings instead of binary multipart — paste the payload, see the picture.
Pulling out embedded attachments from HTML email templates or single-file HTML demos where the image is inlined as a data URI.
Verifying that the encoder side produced a valid round-trip — encode an image elsewhere, paste the result here, confirm the bytes decode back to the same picture.

Frequently asked questions

Why does the tool block image/svg+xml?

SVG is XML and can contain `<script>` elements and inline event handlers (onload, onclick, onerror, onmouseover). When the decoder builds a Blob with type image/svg+xml and calls URL.createObjectURL(), the resulting blob URL inherits the openimages.app origin. Loading such a URL via `<img>` or by navigating to it executes the embedded JavaScript in same-origin context — exactly the same risk class as opening a raw HTML file containing inline scripts. The disclosed advisory of record is CVE-2022-24833 / GHSA-cqcc-mm6x-vmvw (PrivateBin SVG attachment preview blob URL XSS, April 2022); the broader user-upload SVG XSS class is documented in security write-ups (research.securitum.com Bentkowski 2019) and the Angular `DomSanitizer.bypassSecurityTrustResourceUrl` antipattern (angular.dev/best-practices/security). The block is intentional defence-in-depth. To convert SVG, use a server-side renderer that doesn't share its origin with sensitive cookies or storage, or use a desktop image tool.

What is the difference between raw Base64 and a data URI?

A data URI is a Base64 string wrapped in the RFC 2397 URI prefix `data:image/<mime>;base64,<payload>`. The prefix declares the MIME explicitly so receiving software (browsers, image libraries, the decoder here) knows how to render or save the bytes. Raw Base64 is just the payload — the same characters without the prefix — and requires the consumer to already know or guess the MIME. The tool runs the regex `^data:(image/\w+);base64,` to auto-detect; if it matches, the captured MIME is used and the prefix stripped; if it doesn't match, the payload is treated as image/png by default.

Which Base64 standard does the tool follow?

RFC 4648 (Simon Josefsson, IETF October 2006, Standards Track) — the current canonical Base64 specification, obsoletes RFC 3548 from July 2003. The decoder uses window.atob() per the WHATWG HTML Living Standard (html.spec.whatwg.org/multipage/webappapis.html, defined in Web IDL on the WindowOrWorkerGlobalScope mixin), which implements RFC 4648's forgiving variant (whitespace tolerated, `=` padding optional in some cases). Base64's earliest IETF appearance was RFC 989 by John Linn at BBN Communications Corporation (IETF February 1987, PEM Part I — Message Encipherment and Authentication Procedures; obsoleted by RFC 1040 in 1988 then RFC 1113 in 1989), and the canonical pre-RFC 4648 spec was RFC 2045 MIME by Freed & Borenstein, IETF November 1996.

Does decoding lose quality?

No. Base64 is a lossless ASCII representation of the exact binary bytes — every 4 ASCII characters reverse to exactly 3 source bytes (RFC 4648 §4). The decoder produces a byte-identical copy of the file that was originally encoded. The only failure modes are copy-paste damage (missing characters, CR/LF mixed line endings, extra whitespace that's outside the forgiving alphabet) and non-image binary data — atob throws InvalidCharacterError on malformed input.

Is my data uploaded anywhere?

No. window.atob() is a synchronous native browser API that runs entirely in the page's JavaScript context. The Base64 string never leaves your device — there is no fetch() call, no XHR, no analytics beacon carrying the payload. The decoded Blob exists only in your tab's memory; the blob URL is local to your browser and is revoked when you close the page.

RFC 4648 atob() decode + RFC 2397 data URI prefix parsing + SVG XSS rejection

The pipeline parses optional data URI prefixes per RFC 2397 (Larry Masinter, Xerox Corporation, IETF August 1998, Standards Track — defines the `data:[<mediatype>][;base64],<data>` URL scheme), then calls window.atob() per WHATWG HTML Living Standard (html.spec.whatwg.org/multipage/webappapis.html#atob, defined in Web IDL on the WindowOrWorkerGlobalScope mixin since the original WebIDL spec — atob is a synchronous reverse of Base64 over a forgiving Base64 alphabet [A-Za-z0-9+/=] with whitespace tolerated, throwing InvalidCharacterError on malformed input per the spec). The output of atob is a JavaScript string where each character's UTF-16 code unit (0-255) represents one decoded byte; the tool then loops via charCodeAt to populate a Uint8Array (WHATWG TypedArray spec), wraps that into a Blob with the detected MIME (W3C File API), and generates a blob URL via URL.createObjectURL() (W3C File API) for preview and download. The Base64 algorithm itself follows RFC 4648 (Simon Josefsson, IETF October 2006, Standards Track, obsoletes RFC 3548 from July 2003; Base64's first IETF appearance was RFC 989 by John Linn at BBN Communications Corporation, IETF February 1987, PEM Part I — Message Encipherment and Authentication Procedures, obsoleted by RFC 1040 in 1988 then RFC 1113 in 1989; the canonical pre-RFC 4648 spec was RFC 2045 MIME by Freed & Borenstein, IETF November 1996) — the 64-character alphabet A-Z + a-z + 0-9 + + + / with `=` padding produces exactly 4/3 ASCII characters per 3 source bytes. MIME detection: the tool runs `^data:(image/\w+);base64,` against the input — on match, the captured MIME is used and the prefix stripped; on no match, the payload is treated as raw Base64 with image/png as the default fallback. SECURITY: image/svg+xml is REJECTED with an error message. The reason: SVG is XML, can contain `<script>` and JavaScript event handlers (onload, onclick, onmouseover), and a blob URL produced by URL.createObjectURL() inherits the page's origin (openimages.app) — opening or `<img src>`-loading such a blob URL with type image/svg+xml executes the embedded script in same-origin context per the W3C SVG specification and WHATWG fetch + blob URL semantics. The disclosed advisory of record for this exact vector is CVE-2022-24833 (GHSA-cqcc-mm6x-vmvw, PrivateBin SVG attachment preview blob URL XSS, April 2022); the broader user-upload SVG XSS class is documented across security write-ups (research.securitum.com Bentkowski 2019) and the Angular `DomSanitizer.bypassSecurityTrustResourceUrl` antipattern (angular.dev/best-practices/security). The rejection is deliberate defence-in-depth; the check fires post-prefix-extract, so a malicious actor crafting an SVG payload cannot bypass it by re-prefixing the MIME. Convert SVG via a server-side rendering pipeline that doesn't share the origin with sensitive cookies or storage.

Base64 decode per RFC 4648 (Josefsson, IETF October 2006, Standards Track) — obsoletes RFC 3548 July 2003; Base64 history RFC 989 (Linn, BBNCC, February 1987) + RFC 2045 November 1996
Data URI parsing per RFC 2397 (Masinter, Xerox Corporation, IETF August 1998, Standards Track) — `data:[<mediatype>][;base64],<data>` URL scheme
WHATWG window.atob() native browser API — html.spec.whatwg.org/multipage/webappapis.html on WindowOrWorkerGlobalScope mixin, forgiving Base64 alphabet, InvalidCharacterError on malformed input
Auto-MIME detection via regular expression `^data:(image/\w+);base64,` — strips prefix, captures MIME; falls back to image/png when no prefix present
Pipeline: atob() string → charCodeAt loop → Uint8Array → Blob → URL.createObjectURL() blob URL for preview + download (WHATWG TypedArray + W3C File API)
SECURITY: image/svg+xml is REJECTED — SVG can carry `<script>` and inline event handlers (onload/onclick); blob URLs inherit the openimages.app origin, executing scripts in same-origin context
Disclosed advisory of record: CVE-2022-24833 / GHSA-cqcc-mm6x-vmvw (PrivateBin SVG-attachment preview blob URL XSS, April 2022); pattern recurs across user-upload SVG XSS write-ups (research.securitum.com Bentkowski 2019, Angular DomSanitizer.bypassSecurityTrustResourceUrl antipattern)
Browser-native — no SDK, no upload, no server roundtrip; payload stays in your tab

Free. No signup. No file uploads. Ads via AdSense (consent required).

Sources (10)

Josefsson, S. (SJD) (2006). The Base16, Base32, and Base64 Data Encodings. RFC 4648, IETF (October 2006, Standards Track) — obsoletes RFC 3548 (July 2003); §4 standard Base64 with forgiving decode (whitespace tolerated).
Masinter, L. (Xerox Corporation) (1998). The 'data' URL scheme. RFC 2397, IETF (August 1998, Standards Track) — `data:[<mediatype>][;base64],<data>` URL syntax parsed by the tool's `^data:(image/\w+);base64,` regex.
Freed, N. (Innosoft) & Borenstein, N. (First Virtual Holdings) (1996). Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. RFC 2045, IETF (November 1996, Standards Track) — pre-RFC 4648 canonical Base64 spec; §6.8 defines the 64-character alphabet and `=` padding.
Linn, J. (BBN Communications Corporation) (1987). Privacy Enhancement for Internet Electronic Mail: Part I — Message Encipherment and Authentication Procedures. RFC 989, IETF (February 1987) — first IETF appearance of Base64 encoding; obsoleted by RFC 1040 (1988) then RFC 1113 (1989); superseded by RFC 4648.
WHATWG (live). HTML Living Standard — window.atob(). html.spec.whatwg.org/multipage/webappapis.html#atob — synchronous Base64 decode on WindowOrWorkerGlobalScope mixin; forgiving alphabet tolerates whitespace; throws InvalidCharacterError on malformed input.
WHATWG (live). HTML Living Standard — URL.createObjectURL() blob URL semantics. url.spec.whatwg.org + html.spec.whatwg.org — blob URLs inherit the page's origin; loading a blob URL with image/svg+xml MIME executes embedded scripts in same-origin context.
W3C SVG Working Group (2018). Scalable Vector Graphics (SVG) 2. W3C Candidate Recommendation 4 October 2018 — SVG documents support `<script>` elements and inline event-handler attributes (onload, onclick, onerror, onmouseover); scripts execute in document's origin.
Bentkowski, M. (Securitum) (2019). Do you allow to load SVG files? You have XSS!. research.securitum.com — primary-source write-up of SVG-via-user-upload XSS class; documents the `<script>` + `onload`/`onclick`/foreignObject vectors that justify the SVG MIME block.
PrivateBin maintainers (2022). GHSA-cqcc-mm6x-vmvw / CVE-2022-24833 — SVG attachment preview blob URL XSS. github.com/PrivateBin/PrivateBin/security/advisories/GHSA-cqcc-mm6x-vmvw + privatebin.info/reports/vulnerability-2022-04-09.html — the canonical disclosed advisory for the SVG-via-`URL.createObjectURL` same-origin XSS vector this tool defends against.
Angular maintainers (live). Angular Security Guide — DomSanitizer.bypassSecurityTrustResourceUrl misuse. angular.dev/best-practices/security — documents the SVG-resource-URL antipattern where bypassing the sanitiser on untrusted SVG sources permits same-origin script execution.

These are the W3C, ISO/IEC, ITU-T, and IETF specifications the tool implements or builds on. Locate them on w3.org, iso.org, itu.int, or datatracker.ietf.org.