Skip to content
Lizely

Base64 to Image Converter

Turn strict Base64 image data into a validated PNG, JPEG, GIF, or WebP preview and download without uploading it.

Privacy: your files never leave your device. All processing happens locally in your browser.

How to use

  1. 1.Paste strict RFC 4648 Base64 or a data URL containing an explicit ;base64 marker.
  2. 2.Convert the data and confirm the detected format, decoded dimensions, byte size, and preview.
  3. 3.Download the original decoded bytes with an extension chosen from the verified file signature.

About Base64 to Image Converter

Base64 to Image converts strict RFC 4648 Base64 into an image entirely inside your browser. Paste either a plain Base64 payload or a data URL that includes the ;base64 marker, select Convert to image, inspect the decoded preview, and download the original decoded bytes. Nothing is uploaded to Lizely or sent to an external conversion service. The tool is useful when an API response, JSON field, email template, clipboard snippet, browser storage value, or development log contains an image as text and you need a real file for inspection. The decoder deliberately treats Base64 as a byte encoding, not as a trustworthy file label. A data URL may declare image/jpeg while actually containing PNG bytes. In that case the declared MIME value is shown as ignored, the PNG structure wins, the browser validates the bytes as an image, and the download receives a .png extension. This avoids creating a misleading file whose extension was copied from untrusted metadata. Supported output types are PNG, JPEG, GIF, and WebP. PNG preflight requires the complete eight-byte signature, a first IHDR chunk with the mandated length, and a terminal IEND boundary. JPEG requires start-of-image, a following marker, and terminal end-of-image bytes. GIF requires GIF87a or GIF89a, enough bytes for the logical screen descriptor, and the stream trailer. WebP requires RIFF and WEBP markers, an exact RIFF byte count, and a bounded VP8, VP8L, or VP8X first chunk. These structural checks reject bare or truncated magic bytes, but they do not replace image decoding. The browser must also successfully decode the complete Blob and report real, positive dimensions before any preview or download is published. A malformed container that happens to pass basic preflight therefore still fails rather than appearing as a successful conversion. Base64 validation is intentionally strict and deterministic. Input must use the standard RFC 4648 alphabet with plus and slash, must have a length divisible by four, must place one or two padding characters only at the end when required, and must have zero unused pad bits. Whitespace is not removed. Line-wrapped Base64, spaces, tabs, URL-safe minus and underscore characters, missing padding, surplus padding, and noncanonical pad bits produce an explicit error. This strictness is valuable when checking whether a producer generated canonical transport data. If your source provides wrapped MIME Base64 or Base64url, normalize it at the source or with a purpose-built text tool before conversion; this tool does not silently rewrite the input. Data URLs must include a comma separator and exactly one terminal ;base64 token. Media types must use type/subtype syntax, and parameters before ;base64 must use name=value syntax. Duplicate base64 tokens, a parameter after base64, percent-encoded payloads, and non-Base64 data URLs are outside scope. A syntactically valid but false declared MIME type is displayed only as untrusted metadata and never selects the output. Plain Base64 does not need a prefix. The input limit is 8,000,000 UTF-16 code units. The decoded byte limit is 5 MiB, equal to 5,242,880 bytes. The decoder computes the expected output size before allocating the byte array, accepts the exact boundary, and rejects one byte beyond it. It never slices, shortens, samples, or partially decodes oversized input. After browser decoding, width and height must each be no more than 20,000 pixels and their product must be no more than 40,000,000 pixels. These decoded-dimension limits protect browser memory because a compact encoded file can expand into a large pixel surface. The exact limits are accepted; one excess edge pixel or the next representable over-budget dimension pair is rejected. Conversion preserves the decoded bytes. It does not draw onto canvas, resize, recompress, recolor, flatten transparency, or intentionally remove metadata. A downloaded GIF can therefore retain animation, and a PNG can retain alpha and embedded chunks present in the source. Preview behavior still depends on the current browser's image decoder, and metadata display is outside scope. Because the original bytes are preserved, this tool cannot repair a corrupt file, optimize file size, change format, or guarantee that every other application accepts the result. Editing the input immediately removes the previous preview, download, status, error, and busy state. Starting another conversion revokes the old ObjectURL before doing new work. Each asynchronous decode is associated with a generation number, so a late result from older text cannot replace the current state. Temporary ObjectURLs are revoked when replaced, after a failed validation, and when the component unmounts. The decoded image stays local to the active browser tab and is not retained by this tool. Errors distinguish an empty input, input over the character limit, illegal whitespace, malformed data URL, invalid alphabet or padding, non-zero unused pad bits, decoded data over the byte limit, an unrecognized or structurally incomplete container, a corrupt browser-undecodable image, and excessive decoded dimensions. No error path keeps an earlier successful download visible. The preview uses a constrained display size only for page layout; CSS does not resize the downloaded file. The dimension and byte summary refers to the real decoded resource, not the on-screen preview box. Base64 increases transport size and is not usually the most efficient way to store large images. For normal website delivery, use an image file and an appropriate URL where possible. Use this converter for inspection, recovery, debugging, and handoff of already encoded data. Treat unknown image data with the same care as an unknown downloaded file: the browser performs decoding, but conversion is not malware analysis, content moderation, steganography detection, or a guarantee that the image is safe or truthful. For sensitive material, avoid pasting it into shared devices even though the conversion itself remains local. If the preview succeeds but you need a smaller file, download it first and use Image Compressor. If you need different dimensions, use Image Resizer. If you need to inspect or transform arbitrary text Base64 rather than an image, use Base64 Encode and Decode. This focused separation keeps the image workflow predictable while preserving the original image bytes exactly.

Methodology & sources

The parser accepts plain Base64 or an RFC 2397-shaped data URL with a comma, a syntactic type/subtype when present, name=value parameters, and exactly one terminal case-insensitive ;base64 token. It rejects input over 8,000,000 UTF-16 code units and rejects all whitespace. A manual RFC 4648 decoder validates standard alphabet, four-character grouping, terminal padding, and zero unused pad bits, calculates decoded length before allocation, and rejects output above 5,242,880 bytes without truncation. Format preflight requires full PNG signature plus IHDR/IEND boundaries, JPEG SOI/marker/EOI, GIF signature/logical-screen/trailer boundaries, or a size-consistent WebP RIFF with a bounded VP8-family first chunk. The declared data-URL MIME does not select output type. The resulting Blob must decode through createImageBitmap, with an HTMLImageElement fallback only when that API is unavailable. Integer dimensions must be positive, no edge may exceed 20,000 pixels, and total area may not exceed 40,000,000 pixels. The original bytes are downloaded with an extension chosen from detected structure. Job generations and a mounted guard block stale asynchronous results; every ObjectURL is revoked on replacement, failure, or unmount.

Frequently asked questions

Does Base64 to Image upload or store my image?
No. Base64 decoding, signature detection, browser image validation, preview creation, and download all happen in the current browser tab. Temporary ObjectURLs are revoked when replaced or when the tool closes.
Why does valid-looking Base64 fail?
This tool requires canonical RFC 4648 Base64. It rejects whitespace, line wrapping, Base64url characters, missing or misplaced padding, and non-zero unused pad bits instead of silently normalizing them.
What if a data URL declares the wrong image type?
The declared MIME type is not trusted. The tool detects PNG, JPEG, GIF, or WebP from the decoded file signature and uses that detected type for validation, preview, and the download extension.
Does conversion resize, recompress, or remove metadata?
No. The download contains the original decoded bytes. The browser preview is visually constrained, but the file is not redrawn through canvas or intentionally modified.

Related tools

Image Tools guides

View all