Image to Base64 Encoder

Base64 image encoding — when data URIs help, when they hurt

A Base64-encoded image is just a regular image file translated into 64 ASCII characters and embedded inline in your HTML or CSS. The browser decodes it on the fly and renders it just like a fetched file. The trade is intuitive: you trade a network request for a larger document. Whether that trade pays off is more nuanced than the usual "use it for tiny images" rule of thumb suggests. This guide walks through how the encoding actually works (RFC 4648), what it costs in bytes and parser time, the specific cases where inline data URIs win, and the cases where they silently slow your page down.

The mechanics — how Base64 turns binary into text

Base64 (RFC 4648) is a binary-to-text encoding. It takes 3 input bytes (24 bits) and emits 4 output characters (24 bits worth, at 6 bits each). The 64-character alphabet is A–Z a–z 0–9 + /, plus = as padding. A picture of the math:

• Binary input: 0x4D 0x61 0x6E = "Man"
• Bits regrouped into 6: 010011 010110 000101 101110
• Mapped to alphabet: T W F u → "TWFu"

The 33% size overhead is unavoidable: 4 output bytes / 3 input bytes = 1.333. A 30 KB PNG becomes a 40 KB Base64 string. After gzip compression Base64 closes some of the gap (around 70–80% of the source size compresses well), but the inflated payload is what the browser parser has to walk.

Data URIs — the wrapper that makes Base64 usable in HTML/CSS

A data URI (RFC 2397) is the specific URL scheme that lets you put inline content where a URL is normally expected. The structure:

data:[<mediatype>][;base64],<data>

Real examples:

• data:image/png;base64,iVBORw0KGgoAAA… — most common, PNG inline.
• data:image/svg+xml;base64,PHN2Zy… — SVG inline; usually better as plain SVG (skip the encoding overhead).
• data:image/svg+xml;utf8,<svg…> — uncoded SVG; smaller than Base64 but breaks if SVG contains #, ?, or ".
• data:text/html;charset=utf-8,<h1>Hi</h1> — full inline HTML page.

Most browsers cap data URIs at ~32 KB in CSS and ~2 MB in HTML in practice. Older Edge and IE truncated at 4 KB; if you support old Microsoft browsers, keep inline assets under that.

When Base64 inlining wins — and when it loses

The hidden costs of inlining

1. Caching is killed. An external image cached by the browser is reused across pages. An inlined image is downloaded fresh in every HTML response.
2. HTML parser pays the cost. The browser walks every byte of the data URI as part of parsing. Inlining a 50 KB image into your HTML adds 50 KB to LCP-blocking parser time.
3. HTTP/2 and HTTP/3 multiplex. The original "save a request" argument was strongest in the HTTP/1.1 era when each connection was sequential. With HTTP/2 server push and HTTP/3 multiplexing, the cost of a separate image request is much smaller.
4. CDN compression skips inlined assets. Your CDN compresses HTML once, then transparently re-uses that for every visitor. An external PNG/JPG goes through the CDN's image optimization pipeline (WebP/AVIF transcoding, resizing). Inline images get neither.
5. Content-Security-Policy headaches. A strict CSP with img-src 'self' blocks data URIs unless you add data: — which weakens the policy.

Generating data URIs in 6 languages

The picker handles the browser case. For build pipelines, here is the same conversion in code:

const fs = require('fs');
const buf = fs.readFileSync('icon.png');
const dataUri = `data:image/png;base64,${buf.toString('base64')}`;

import base64, mimetypes
mime = mimetypes.guess_type('icon.png')[0]
data = base64.b64encode(open('icon.png','rb').read()).decode()
print(f"data:{mime};base64,{data}")

import ("encoding/base64"; "net/http"; "os")
b, _ := os.ReadFile("icon.png")
mime := http.DetectContentType(b)
fmt.Printf("data:%s;base64,%s", mime, base64.StdEncoding.EncodeToString(b))

$data = file_get_contents('icon.png');
$mime = mime_content_type('icon.png');
$uri  = "data:$mime;base64," . base64_encode($data);

require 'base64'
require 'mime/types'
data = Base64.strict_encode64(File.binread('icon.png'))
mime = MIME::Types.type_for('icon.png').first.to_s
"data:#{mime};base64,#{data}"

echo "data:image/png;base64,$(base64 -w 0 icon.png)"

SVG — the special case where Base64 is wrong

SVG is already a text format. Base64-encoding it adds 33% with zero benefit. Two better options:

• Inline SVG element: <svg viewBox="…">…</svg> directly in HTML. Smallest, fully styleable with CSS, animatable.
• URL-encoded data URI: url("data:image/svg+xml;utf8,<svg …/>") with #, ", and % percent-encoded. Smaller than Base64.

For a 1 KB SVG icon, the URL-encoded form is ~1 KB; the Base64 form is ~1.33 KB; the inline element is ~1 KB and lets you change fill on hover. Inline wins when you can.

Common Base64-image mistakes

• Inlining hero / above-the-fold images. A 200 KB hero image inlined turns into 270 KB blocking the HTML parser. Serve the image with <link rel="preload"> instead.
• Inlining everything in a single CSS file. The CSS file balloons, blocks render, and never caches an updated icon independently.
• Forgetting the MIME type. data:base64,iVBOR… (no image/png) renders nothing in most browsers.
• Pasting raw output to JSON. JSON allows + and / just fine, but URL Base64 (RFC 4648 §5) uses - and _ instead. Don't mix the two encodings.
• Inlining user-uploaded photos. 2 MB photo + 33% overhead = a 2.7 MB HTML response. CDN your uploads.
• Embedding a Base64 image in an alt attribute. Some teams paste the URI into alt by mistake — accessibility tools then read out 50 KB of garbage.