How to Convert an Image to Base64 (and Why the Data URI Has a 33% Size Tax)

The problem: you need an image inside a file, not next to it

You're sending an email with a logo, building an HTML widget that can't make a second HTTP request, or storing a thumbnail in a JSON field. A separate .png file won't work — the email client blocks external images, the widget has no asset server, the JSON schema has no file URL field. You need the image inside the document. That's what Base64 is for, and the cost is a 33% size tax and a rendering trade you should understand before you paste.

Fastest path

Open the Image to Base64 Converter, drop the image, pick an output mode, copy.

Input:   logo.png (4.2 KB, 120x40)
Output:  data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAH...
Size:    5.6 KB (+33%)

That string is the entire image. Paste it into an <img src="…">, a CSS background-image: url(…), or a JSON field, and the image renders with no second request. The tool also hands you ready-made HTML, CSS, JavaScript, and React snippets with the Data URI already inlined, so you don't have to wire the string in by hand.

The substance: what Base64 is, and what the Data URI does

Base64 is an encoding that takes any binary blob and represents it as printable ASCII — the 64 characters A-Z, a-z, 0-9, +, /. Every 3 bytes of input become 4 characters of output. That's where the 33% size increase comes from: 3 bytes → 4 chars is a 4/3 ratio, and the tool shows it as a +33% badge on every conversion. A 4.2 KB PNG becomes a 5.6 KB Base64 string. That string is plain text, so it rides anywhere text can ride — HTML, CSS, JSON, a database text column, an email body.

A Data URI is the wrapper that makes a browser treat that text as an image. The format is:

data:<mime>;base64,<base64-string>

So data:image/png;base64,iVBOR... tells the browser "this isn't a URL, it's a PNG image, here's the Base64." Drop it in an <img src> and the browser decodes it inline. The tool's "Data URI" mode gives you the whole thing; "Raw Base64" gives you just the string after the comma, for APIs that want the bare payload.

The five output modes, and when each is right

Mode	What you get	Use when
Data URI	`data:image/png;base64,...`	You need the full inline string for an arbitrary use
Raw Base64	just the base64 chars	An API expects the bare encoded payload
CSS	`background-image: url(data:...)`	You're styling an element and want the image baked in
HTML	`<img src="data:..." width="..." height="...">`	A single image tag ready to paste
Markdown	`![name](data:...)`	A README or doc that has to render without an asset folder

The HTML and CSS modes include the original dimensions (width and height), which matters — setting them prevents the layout shift that happens when the browser decodes the image and reflows. The Markdown mode works in most renderers but some (notably GitHub) block Data URIs in READMEs for security, so test before you commit.

The format conversion lever

Before Base64 even applies its 33% tax, you can shrink the image with the format selector. A 24 KB PNG screenshot re-encoded as WebP at 80% quality drops to ~6 KB; after Base64 it's ~8 KB. That's a 67% saving before the tax, and the tax is smaller in absolute terms because it's 33% of a smaller number. The tool uses a canvas to re-encode: it draws the image, then calls canvas.toDataURL('image/webp', 0.8). Quality only applies to JPEG and WebP — PNG is lossless and ignores it.

This is the single biggest lever for keeping Base64 small. Don't encode a 2 MB PNG and ship a 2.7 MB Data URI. Re-encode to WebP first.

The trap: when not to use Base64

The 33% tax is the headline cost, but the real cost is what Base64 does to the browser.

No parallel fetching. A page with 20 separate image files loads them in parallel — the browser fans out 6 concurrent requests. A page with 20 inlined Base64 images loads them in sequence, as part of the HTML, on the single document request. One big file beats twenty small ones only when the small ones are tiny.

No caching. A regular PNG at https://site.com/logo.png is cached on the first load and served from disk on every subsequent page. A Base64 Data URI is part of the HTML, so it's re-downloaded every time the HTML is re-downloaded. For a logo on every page of a site, inlining it makes every page heavier.

Blocks rendering. A big Base64 string in the HTML blocks the initial parse. The browser can't paint the page until it has the document, and the document is now 200 KB larger because you inlined a hero image.

The rule: inline small images, serve large images as files. The tool warns you at 50 KB of Base64 — that's a reasonable ceiling for icons, bullets, and small logos. Anything bigger should be a real file with a URL, cached and loaded in parallel.

The decode path

The tool also decodes — paste a Base64 string, a Data URI, a CSS url(...) value, or a quoted string, and it renders the image and reports the dimensions. It strips the url() wrapper and the surrounding quotes, adds the data:image/png;base64, prefix if you pasted raw Base64, and validates by loading the image. If the string is malformed or the MIME type is wrong, the load fails and you get "Invalid Base64." The decode is useful when you inherit a codebase full of inlined images and need to extract one as a real file — decode it, click Download PNG, and you're out.

Gotchas

The 33% tax is unavoidable. Base64 encodes 3 bytes as 4 chars. There's no compression. If the input is already small (an icon, a bullet), the tax is negligible. If it's a photo, the tax is a third of a photo.
Re-encode to WebP or JPEG before encoding to Base64. The format selector and quality slider are the biggest size levers. A PNG→WebP conversion at 80% quality can cut the base64 by 60%+ before the 33% tax even applies.
URL loading is CORS-gated. "Load from URL" sets crossOrigin = 'anonymous', so any image whose server doesn't send Access-Control-Allow-Origin will fail. You can't Base64-encode a random image from the web without the server's cooperation — by design, to prevent cross-origin data theft.
SVG and BMP are accepted but behave differently. SVG inlined as a Data URI renders as an image (no script execution, no external references). BMP is large and rarely worth inlining — convert to PNG or WebP first.
GitHub blocks Data URIs in READMEs. The Markdown mode works in most renderers, but GitHub strips data: URLs in markdown for security. If the README is for GitHub, use a real file in the repo.
Email clients are inconsistent. Gmail strips Data URIs on some platforms. Outlook desktop supports them in <img src>, Outlook web often doesn't. Test in the actual client before you ship a Base64 email to a list.
Large Base64 strings block rendering. The tool warns at 50 KB. That's a good ceiling for inline use. Over 50 KB, serve a file.
No caching across pages. A Base64 logo on every page is re-downloaded with every HTML response. For site-wide assets, a cached PNG wins on the second pageview.

Summary

Base64 encodes 3 binary bytes as 4 ASCII chars — a 33% size tax, no compression. Use it when the image has to live inside a document (HTML, CSS, JSON, email), not next to it.
A Data URI (data:image/png;base64,...) is the wrapper that makes a browser treat the string as an image. The tool's five output modes give you Data URI, Raw Base64, CSS, HTML, and Markdown — pick the one that matches where the string lands.
Re-encode to WebP or JPEG before Base64 to shrink the payload before the 33% tax applies. A PNG→WebP at 80% quality can cut the final string by 60%+.
Inline small images only. The tool warns at 50 KB of Base64. Over that, serve a real file — Base64 blocks rendering, can't be cached across pageviews, and kills parallel fetching.
Convert images at the Image to Base64 Converter; pair with Image Resizer to shrink dimensions before encoding, Favicon Generator for the most common Base64 use case (inline favicons), and PNG to WebP Converter to cut the size before the tax.

Related Tools