Image to Base64 Converter

Image to Base64 and back, explained

Base64 encoding turns binary image data into plain text so it can travel inside formats that only accept characters — HTML, CSS, JSON, SVG, or a copy-and-paste email. This tool converts in both directions: it encodes any image into a ready-to-paste data URI, and decodes a Base64 string or data URI back into a downloadable image file.

How the conversion works

Encoding reads your file with the browser's FileReader API and returns a complete data:[mime];base64,… string, along with the original and encoded sizes so you can judge the overhead. Decoding parses the MIME type out of the data URI, rebuilds the raw bytes, and hands you a real Blob you can preview and save. Because every 3 bytes become 4 characters, the encoded text is always about a third larger than the source.

The size overhead, with real numbers

Base64 packs every 3 bytes of binary into 4 printable characters, so the text is always about 33% larger than the file it came from — a 1.5 KB icon becomes roughly 2 KB of string, a 40 KB photo becomes about 53 KB, and a 1 MB image balloons past 1.3 MB. On top of that comes the data-URI prefix itself (data:image/png;base64,is 22 characters) and, once it lands in HTML or CSS, that bloated payload sits in the markup uncompressed unless your server applies gzip or Brotli — which recovers some, but not all, of the penalty because Base64's restricted alphabet is less compressible than raw text.

When inlining helps

• Tiny, critical icons— inlining a sub-2 KB logo or UI glyph removes an HTTP round-trip on first paint, and at that size the 33% penalty is a few hundred bytes you'll never notice.
• Self-contained files — single-file HTML emails, exported reports, or SVGs that must carry their own raster artwork with no external dependencies.
• Config and data payloads — slipping a small image into a JSON API response or a theme file where a separate request would be awkward.

When inlining hurts

The economics invert as the image grows. A hosted file is fetched once and then served from the browser cache on every later page; an inlined data URI is re-downloaded in full with the HTML or CSS every single time, because it has no independent cache entry. Inline a 200 KB hero image and you have added 260 KB to the render-blocking stylesheet that must arrive before the page can paint — the opposite of the latency win you got from a tiny icon. Large data URIs also bloat the DOM, make source files unreadable, and can't be lazy-loaded. The rule of thumb: inline assets in the low single-digit kilobytes, host everything else.

Everything runs in your browser

Both directions use plain browser APIs in this tab, so the tool keeps encoding and decoding on a plane or a locked-down network where an upload-based converter would simply fail.

Tips for clean results

• Match the MIME prefix to the real image type, or some browsers silently refuse to render it.
• Compress or resize before encoding — a smaller source means a far shorter string.
• When pasting into CSS, keep the whole data URI on one line to avoid accidental whitespace breaks.

Related image tools

• Base64 Encoder / Decoder — same encoding, for text and non-image binary data.
• Image Compressor — every KB you cut off the source is ~1.3 KB off the string.
• Image Resizer — shrink an icon to its display size before you inline it.
• Image Converter — pick the format with the smallest bytes to encode.