Image to Base64 Converter

What this converter does

It re-expresses an image file's bytes in Base64, the 64-character alphabet (A–Z a–z 0–9 + /) that lets binary data travel through text-only channels — HTML, CSS, JSON, email. Drop an image on the left and four copy-ready outputs appear instantly: the raw Base64 string, a complete data: URI, an HTML <img> tag and a CSS background-image rule. The file is read with FileReader and encoded byte-for-byte — no canvas, no recompression — so decoding the output reproduces your original file exactly. The reverse direction takes any Base64 string or data: URI and turns it back into a visible, downloadable image.

The size cost, honestly

Base64 maps every 3 bytes of input to 4 output characters, so the encoded form is always about 33% larger than the file (4 ÷ 3 ≈ 1.333, plus up to two = padding characters). A 12 KB icon becomes ~16 KB of text; a 300 KB photo becomes ~400 KB. The badges above the output show the exact before/after for your file. Note what the encoding does not do: it does not compress, resize or optimise anything. If the input is bloated, the Base64 is 133% of bloated — shrink the image first with the Image Compressor or Image Resizer, then encode the smaller file.

When inlining helps — and when it hurts

A data URI saves one HTTP request because the image arrives inside the document itself. That is a real win for tiny assets: a 1 KB SVG icon, a 2 KB logo in an email signature (where remote images are often blocked), a favicon in a single-file HTML report, or a texture in a self-contained demo. It is a loss for anything bigger, for three concrete reasons:

• Caching breaks. A normal image URL downloads once and is cached; an inlined image re-downloads with every page and every stylesheet that embeds it. Ten pages sharing one inlined 100 KB header image transfer ~1.3 MB instead of ~100 KB.
• The document blocks. Those extra kilobytes sit in your HTML or CSS, which the browser must download and parse before rendering — a large inline image in CSS delays first paint for the whole page, whereas an <img> URL loads in parallel and can be lazy-loaded.
• It compounds. The +33% overhead applies on top; gzip claws some back but the decoded bytes still occupy memory as text and again as pixels.

A practical threshold: inline below roughly 2–4 KB, serve as a file above it. With HTTP/2 multiplexing, the per-request saving that once justified aggressive inlining is smaller than it used to be.

Decoding: what the badges mean

The decode tab accepts a full data: URI or a bare Base64 string, tolerating line breaks, spaces and the URL-safe -_ alphabet. The format badge comes from the data's own magic bytes — PNG bytes always encode to a Base64 string starting iVBORw0KGgo, JPEG to /9j/, GIF to R0lGOD and WebP (RIFF) to UklGR — so a wrong or missing mime label in the pasted URI cannot fool it. The pixel dimensions are read from the actually-rendered image, and Decoded is the real byte size of the file the Download button saves. Invalid input tells you specifically what is wrong — an illegal character, impossible padding, a 4n+1 length, or valid Base64 with no image signature — instead of showing a broken image icon.

Honest limits

Everything runs in your browser's memory, so very large files (tens of MB) make the output textareas sluggish — the display truncates past 500,000 characters, though Copy always copies the complete string. The decoder recognises PNG, JPEG, GIF, WebP and SVG; other formats (AVIF, TIFF, BMP) decode as valid Base64 but are refused as "no image signature" even though the bytes may be a real image. And to restate the core caveat: this tool changes the representation, never the image — for making files smaller, use a compressor; for plain text↔Base64, use the Base64 text tool.