Base64 Images:
Encoding, Decoding & Data URIs

Why Images Get Encoded as Text

Images are binary data. The web is built on text. Base64 bridges that gap. It converts the raw bytes of a PNG or JPEG into a string of 64 printable characters — letters, digits, plus, and slash — that can travel through any text channel: HTML attributes, CSS properties, JSON payloads, or email headers.

Base64-encoded images show up everywhere once you start looking. That src="data:image/png;base64,iVBOR..." in an HTML file? Base64. The profile picture embedded in a JWT? Base64. The email attachment that looks like a wall of random characters? Also Base64. This guide explains how to work with Base64 images — encoding them, decoding them to view, and knowing when this approach makes sense versus when it doesn't.

How Base64 Image Encoding Works

The Encoding Process

Base64 takes binary data (the image file) and processes it in 3-byte chunks. Each chunk of 24 bits is split into four 6-bit groups. Each 6-bit value (0-63) maps to a character: A-Z for 0-25, a-z for 26-51, 0-9 for 52-61, + for 62, and / for 63. If the input isn't a multiple of 3 bytes, padding with = characters fills the gap.

The result is a data URI — a self-contained string that includes the MIME type and the encoded data. A PNG image becomes something like:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVR42mP8/5+hHgAHggJ/PchI7wAAAABJRU5ErkJggg==

That entire string is a valid image. Paste it in a browser's address bar and you'll see the picture. No file, no server request — just self-contained data. The Image to Base64 tool does this conversion in your browser, with no upload to any server.

The Size Tradeoff

Base64 encoding increases data size by approximately 33%. Every 3 bytes of image data become 4 Base64 characters. So a 100KB image becomes a ~133KB string. If that string is then compressed with gzip (as most web servers do for HTML and CSS), the overhead drops to about 2-3% because the Base64 alphabet compresses well.

This size overhead is the key factor in deciding whether to Base64-encode an image. For a 2KB icon, a 33% increase is negligible. For a 500KB photograph, you're adding 165KB to your HTML or CSS — on a slow connection, that matters. Generally, inline Base64 images are worth it for anything under 5-10KB and not worth it for anything above that threshold.

When to Use Base64 Images

Good Use Cases

• Small icons and logos — under 5KB. Eliminating an HTTP request for a tiny file can be faster than the request overhead itself. On HTTP/1.1, each request has significant latency. On HTTP/2 and HTTP/3, the benefit is smaller but still real for critical-path assets.
• Email signatures — email clients often block external images. A Base64-embedded logo always displays because it's part of the HTML, not a separate download. This is why corporate email signatures often embed their logo as a data URI.
• Single-file HTML reports — dashboards, invoices, or certificates that need to be self-contained. Embedding images means one file to share, no broken image links.
• CSS background images — small repeating backgrounds or icons in stylesheets. Embedding them avoids separate sprite file management.
• API responses — some APIs return images as Base64 strings in JSON. This is common in document processing APIs, OCR services, and some database-driven CMSs.

When to Avoid

• Large images — anything over 50KB should almost certainly be a separate file. The size overhead and the lack of caching override any benefit.
• Images that change independently — if your HTML changes daily but your logo changes yearly, keeping the logo as a separate file lets the browser cache it across page loads.
• Social media preview images — Open Graph and Twitter Card meta tags need actual URLs, not data URIs. Base64 won't work for og:image.

Decoding Base64 to View Images

The Reverse Process

You encounter a Base64 image string — in a database export, an API response, or a log file — and you need to see what it actually looks like. The reverse process is: strip the data URI prefix if present, decode the Base64 string to bytes, and render the bytes as an image.

In the browser, this is trivial — set an <img> tag's src to the data URI and the browser handles the rest. But doing it programmatically or verifying that the string is a valid image requires a few steps:

// Raw Base64 string → viewable image
const base64 = "iVBORw0KGgoAAAANSUhEUgAAAAE...";
const dataUri = `data:image/png;base64,${base64}`;

// Display it
const img = document.createElement('img');
img.src = dataUri;
img.onload = () => console.log(`${img.naturalWidth}x${img.naturalHeight}`);
img.onerror = () => console.error('Invalid image data');

The Base64 Image Viewer does this instantly. Paste any Base64 string or data URI, click View Image, and see the decoded picture along with its dimensions, format, and file size. It detects the image format automatically from the data URI or Base64 header bytes.

Handling Raw vs Data URI Strings

Base64 image strings come in two flavors. A data URI includes the MIME type prefix (data:image/png;base64,...). A raw Base64 string is just the encoded data without the prefix. Most tools and libraries expect one or the other — make sure you know which you're working with. Data URIs are more portable because they carry their own type information.

Data URIs Beyond Images

The data URI scheme isn't limited to images. You can encode any file type:

• PDF: data:application/pdf;base64,... — embed a document preview inline.
• Fonts: data:font/woff2;base64,... — inline critical fonts to avoid FOIT (Flash of Invisible Text).
• Audio: data:audio/mp3;base64,... — rare, but valid.

Each has the same tradeoff: self-contained data at the cost of size overhead and no independent caching. It's a tool in your toolkit, not a silver bullet.

Security Considerations

Base64 is encoding, not encryption. Anyone can decode a Base64 string back to the original bytes — that's the entire point. Never use Base64 to "hide" sensitive data. If you're storing images that contain personal information, the Base64 representation is just as sensitive as the original file.

One practical security note: data URIs bypass some Content Security Policy (CSP) restrictions. If your CSP allows img-src 'self' data:, then Base64-encoded images will load regardless of their origin. For most applications, this is fine and expected. For strict CSP configurations, be aware that data: URIs are a separate source directive.

The Complete Base64 Image Workflow

Here's the end-to-end flow for working with Base64 images:

1. Encode: Drag an image into the Image to Base64 converter. Get back a data URI or raw Base64 string — your choice.
2. Embed: Drop the data URI into an HTML <img src="..."> or a CSS url(...) declaration. The image is now self-contained.
3. Decode & View: Received a Base64 image from an API or database? Paste it into the Base64 Image Viewer to see it instantly, check its dimensions, and download it as a file.

These two tools — one for encoding, one for decoding — cover the complete workflow. Both run entirely in your browser, so your images never touch a server.