CruxDevCruxDev Tools Prompts
file Utility • Zero-Server Privacy • 100% Client-Side

Image ↔ Base64

Convert images to Base64 data URIs for use in CSS, HTML, or APIs. Decode back to image.

Overview

Convert images to Base64 and back, in both directions, entirely in your browser. Encoding produces a data URI, bare Base64, an <img> tag, a CSS background rule or a Markdown image, ready to paste into HTML, CSS, JSON or a README; decoding takes a data URI, a bare Base64 string or a url(...) or <img> snippet, previews the image and offers a download. Built on the FileReader API with no uploads and no size games.

How It Works

The encode tab is the default: drop, select or paste (Ctrl+V) an image, so a screenshot straight from the clipboard works, and the page shows a preview plus the image's name, detected type, file size, pixel dimensions, Base64 length and size overhead. Pick an output - Data URI, Base64 only, <img> tag, CSS background or Markdown - then Copy it or Download it as a .txt, .html, .css or .md file. On screen the text is cut off above 200,000 characters to keep the page responsive, but Copy and Download always include the complete output. Switch to the decode tab and paste a data URI, a bare Base64 string (standard or URL-safe), a percent-encoded SVG data URI, or a CSS url(...) or <img> tag; the image is rendered with its real dimensions and format, and you can download it with the right extension or copy a clean data URI. Invalid input is caught and reported rather than rendering a broken image.

Step-by-Step Usage Guide

  1. Drop, select or paste (Ctrl+V) an image on the encode tab.
  2. Choose Data URI, Base64 only, <img> tag, CSS background or Markdown, then copy or download it.
  3. Switch to the decode tab and paste a data URI, bare Base64, or a url(...) or <img> snippet.
  4. Check the rendered image and its detected format, then download it or copy a clean data URI.

Technical Specifications & Standards

The file is read as raw bytes with FileReader and the image type is identified from the bytes themselves - PNG, JPEG, GIF, WebP, AVIF, BMP, ICO and SVG - rather than from File.type, which browsers leave empty or wrong for .ico, .avif and sometimes .svg files and which would otherwise yield an unrenderable data:application/octet-stream URI. File.type is only a fallback for an image type the byte check does not recognise. The bytes are Base64-encoded unchanged, so a PNG in is the same PNG's bytes out, unlike canvas-based converters that resample the image. Base64 inflates size by about a third (four characters per three bytes), which is the arithmetic behind the standard advice: inline only small images, such as icons, and keep photographs as separate files. The decode side is deliberately forgiving: it unwraps url(...) and <img src=...> wrappers and surrounding quotes, accepts a full data URI or bare Base64, converts the URL-safe alphabet (- and _) and restores missing = padding, and percent-decodes non-Base64 data URIs such as the common data:image/svg+xml,%3Csvg... form. The type of a decoded image also comes from its bytes, so a bare JPEG downloads as .jpg instead of being assumed to be PNG, and when a data URI declares a MIME type that disagrees with the bytes the page shows a warning and the download and the clean data URI use the real type. Validation happens by actually rendering the decoded bytes - if the browser can draw it, it is a real image. Decoding is a pure byte transform, so nothing checks whether the image is safe to render beyond the browser's own image decoder, which is the same one every web page uses.

Targeted Use Cases

  • Inlining a small logo as a data URI to remove an HTTP request.
  • Embedding an image in a JSON payload or single-file HTML.
  • Decoding a Base64 image from an API response to check its content.
  • Converting a data URI back into a real file for editing.

Notes & Gotchas

  • Inline only small images; Base64 costs about 33 percent extra bytes and cannot be cached separately.
  • Use Base64 only for contexts that add their own prefix, such as some CSS or API fields, and the CSS background or <img> tag output when you want a ready-to-paste snippet.
  • On decode, trust the rendered preview and the reported format over the declared MIME in the string - both come from the actual bytes.
  • SVG works on both tabs, but check sanitisation before embedding untrusted SVG in HTML.

Frequently Asked Questions

Why is the Base64 string longer than my file?

Base64 encodes three bytes as four characters, a fixed 33 percent overhead, plus the data URI prefix. That is inherent to the encoding, not a conversion inefficiency.

Does encoding re-compress or alter my image?

No. The data URI is built from the file's exact bytes via FileReader, so it decodes back to a byte-identical image - unlike canvas-based converters. The image type in its prefix is detected from those bytes, not taken from the file's reported type.

What does the decode tab accept?

A full data URI, a bare Base64 string (standard or URL-safe, with or without = padding), a percent-encoded SVG data URI, or a CSS url(...) or <img src> wrapper around any of them. The format - PNG, JPEG, GIF, WebP, SVG and so on - is detected from the decoded bytes, and the image is validated by rendering it.

Where should I use the data URI instead of a file?

Small, cache-independent assets: icons, dividers, placeholder graphics. Large or frequently updated images are better served as separate, cacheable files.