Image to Base64

What is a Base64 image (data URI)?

A data URI embeds an image directly inside text instead of pointing to a separate file. It has the form data:<mime>;base64,<encoded-bytes> — for example data:image/png;base64,iVBORw0KGgo…. Because it is plain text, you can drop it straight into HTML, CSS, JSON, SVG or Markdown, and the browser renders the image without a second network request. Encoding never changes the picture — it is a byte-for-byte text representation of the exact file you gave it.

Size & caching — the trade-off

Base64 turns every 3 bytes into 4 ASCII characters, so the encoded text is always about 33% larger than the binary file, plus a short header. That is fine for a few tiny assets but wasteful for large ones. The bigger catch is caching: a linked image file is downloaded and cached once, then reused everywhere, while an inlined data URI is re-downloaded as part of every page or stylesheet that contains it, and cannot be cached on its own. Inline small, link large.

When to inline vs link

Tips

• Compress or resize first. Base64 of a smaller image is a smaller string — run a photo through the Image Compressor or Image Resizer before encoding.
• SVG inlines especially well — vector icons stay sharp and compress better than raster as Base64; great for CSS backgrounds and component libraries.
• Watch HTML/CSS size. A handful of inlined icons is fine; dozens of large data URIs make your markup heavy and slow to parse.
• Need text, not images? Use the Base64 Encoder / Decoder for plain text and strings.

How Base64 actually works

Base64 is a way of writing binary data using only a small set of safe text characters. Its alphabet is exactly 64 symbols — the uppercase letters A–Z, the lowercase a–z, the digits 0–9, plus + and / — and the standard is defined in RFC 4648. The encoding works in a fixed rhythm: it takes the data three bytes (24 bits) at a time and rewrites them as four characters of 6 bits each (since 2⁶ = 64, every character maps cleanly to one alphabet symbol). When the data doesn't divide evenly into threes, one or two = characters pad the end.

That 3-bytes-to-4-characters ratio is precisely where the ~33% size increase comes from: four output characters for every three input bytes is a 4/3 expansion. There is also a common cousin, base64url, which swaps + and / for - and _ so the result is safe to drop into a URL or filename without further escaping — it is the variant used inside JSON Web Tokens (JWTs).

The data URI scheme

Wrapping that Base64 in a usable address is the job of the data URI scheme, defined in RFC 2397 back in 1998 by Larry Masinter. The grammar is data:[<mediatype>][;base64],<data>. A few details are worth knowing: the comma is always required, even for empty data; the ;base64 token is what signals that the payload is Base64 rather than percent-encoded text; and if you omit the media type entirely, the default is text/plain;charset=US-ASCII. For an image you'll always see an explicit type such as data:image/png;base64,… so the browser knows how to decode it. This is also why this tool reports the MIME type — it is read straight from your file, so the URI is correct for that exact format.

Why Base64 exists at all

Base64 wasn't invented for the web — it comes from email. The original mail protocols were designed to carry only 7-bit ASCII text, with no safe way to send the arbitrary bytes of an image or attachment. The MIME standards solved this by re-encoding binary into a text alphabet that survives any text-only channel intact, and Base64 became that encoding. A data URI is the same idea applied to a web page: turn a picture into text so it can live inside the HTML or CSS instead of being a separate file.

This history points to the single most important thing to understand about Base64: it is an encoding, not compression and not encryption. It does not make data smaller — it makes it about a third larger — and it does not secure anything, because anyone can decode it instantly (this very tool will). If you see Base64 and assume it is "encrypted", you are mistaken; it is just binary dressed up as readable text.

Does inlining still help performance?

The classic argument for data URIs was eliminating HTTP requests, and under HTTP/1.1 — where browsers could only open a few connections per host — saving a round trip was a real win. HTTP/2 changed the maths: it multiplexes many files over one connection, so the cost of an extra request dropped sharply and the case for inlining weakened. There is also a subtler tax: Base64 text compresses less efficiently with gzip or Brotli than the equivalent raw binary, so some of the bytes you "saved" on a request come back on the wire. The durable rule of thumb is simply inline small, link large — a tiny critical icon can still be worth inlining to avoid a render-blocking request, but anything substantial should stay a normal, separately-cacheable file. (One neat exception: for an SVG, URL-encoding the markup is usually smaller than Base64-encoding it, because SVG is already text and doesn't benefit from the Base64 wrapper.)

A note on security and Content Security Policy

Because a data URI can carry any content, it has security implications worth flagging. Under a Content Security Policy, allowing data: in img-src is common and fairly low-risk (it is how inline icons work), but allowing data: in script-src is dangerous — an attacker could smuggle and run code via a data: script URL, so security guides recommend never permitting it there. Data URIs have also been abused to build phishing pages, which is why modern browsers now block top-level navigation directly to a data: URL. None of this affects encoding an image for your own page; it just means you should treat a data URI as the active content it is, not as inert text.

The browser APIs behind it

This converter is built on the browser's own FileReader.readAsDataURL(), which reads your file locally and hands back the complete data:<mime>;base64,… string — the "Raw Base64" output is simply that string with the prefix stripped off. You may also have met btoa() and atob(), the low-level encode and decode functions. They carry a famous gotcha: btoa() treats each character as a single byte, so it throws an error on any character above U+00FF — feed it an emoji or a non-Latin character and it fails. The modern fix is to convert text to bytes with TextEncoder first (or use the newer Uint8Array Base64 helpers). For images this never comes up, because readAsDataURL works on raw bytes — which is exactly why it is the right tool for the job here.

Where a data URI actually goes

Once you have the encoded string, the question is where to paste it. The same data URI works in several contexts, which is why this tool builds ready-made snippets for the common ones:

Each of these embeds the picture directly in the document, so there is no second request for a separate image file. That is the whole appeal — and, as covered above, the whole trade-off, because the bytes ride along inside the host file every time it loads.

Why data URIs are reliable in email

One context deserves special mention: email. Many email clients block remote images by default — they won't load a picture hosted on an external server until the reader clicks "show images", partly as a privacy measure against tracking pixels. An image embedded as a data URI sidesteps that entirely, because nothing has to be fetched from anywhere; the picture is already inside the message. That makes data URIs a dependable way to put a small logo into an HTML email signature, where you want it to appear every time, on every client, with no broken-image placeholder. The same caution still applies — keep it small, since the encoded bytes travel inside every copy of the email.

The caching cost, spelled out

It is worth being concrete about the biggest downside, because it is the one people overlook. A normal linked image is downloaded once and then served from the browser cache on every later page — fast, and free of extra bytes. An inlined data URI cannot be cached on its own; it lives inside the HTML or CSS file, so it is re-downloaded as part of that file every time the file changes, and it can't be shared between pages. Inline the same icon on twenty pages and the browser effectively downloads it twenty times instead of caching one copy. This is the deciding factor behind the "inline small, link large" rule: a tiny one-off asset is fine to embed, but anything reused across pages almost always belongs in a separate, cacheable file.

Anatomy of a data URI, field by field

A data URI looks like a wall of random characters, but it has a clear, readable structure. Take data:image/png;base64,iVBORw0KGgo… and break it into its parts:

There is even a fun tell hidden in the payload: a Base64 string that begins iVBORw0KGgo is almost always a PNG (those characters encode the PNG file signature), while one starting /9j/ is a JPEG. Once you can read the parts, a data URI stops being mysterious — it is just a media type, the word base64, and the encoded file, joined by a comma. That is exactly the string this tool's "Data URI" box gives you, and the "Raw Base64" box is the same thing with everything up to and including the comma removed.

Turning a data URI back into a file

Because Base64 is a reversible encoding, the process runs both ways — which is what the "Base64 → Image" tab above does. Paste in a full data: URI, or just the raw Base64 with the format selected, and the tool decodes the text back to the original bytes, previews the picture, and lets you download it as a real file. The decode simply reverses each step: it reads the media type to know the file format, strips the data:…;base64, prefix, and turns every four Base64 characters back into three bytes. If the string isn't valid image data — a truncated copy-paste is the usual culprit — you'll get a clear error rather than a broken image, since the bytes won't decode into a picture the browser can render. It is the exact inverse of encoding, and a handy way to recover an image someone has embedded as a data URI in a stylesheet or HTML file.

Frequently asked questions

Is my image uploaded to a server?

No. The image is read entirely in your browser with the built-in FileReader API and converted to Base64 locally — it never leaves your device and is never logged or transmitted. It works offline once the page has loaded, which is why it is safe for private screenshots, ID photos or internal assets.

What is a data URI and where do I paste the result?

A data URI looks like data:image/png;base64,iVBORw0KGgo… — the MIME type, the word base64, then the encoded bytes. You can drop the whole string straight into an HTML <img src="…">, a CSS background-image: url("…"), or a Markdown image. This tool builds those three snippets for you so you can copy the exact one you need.

Why is the Base64 bigger than the original file?

Base64 encodes every 3 bytes as 4 ASCII characters, so the text is always about 33% larger than the binary image — plus the short data:…;base64, header. That is the trade-off for embedding an image directly in text. It is fine for small assets but wasteful for large photos, which are better linked as a normal file.

Which image formats can I encode?

Any format your browser can read as a file — PNG, JPEG, GIF, WebP, SVG, BMP and ICO all work. The MIME type is taken from the file itself, so the resulting data URI is correct for that format. Encoding does not change or re-compress the image; it is a byte-for-byte text representation of the original file.

Can I decode a Base64 string back into an image?

Yes — switch to the “Base64 → Image” tab and paste either a full data URI or just the raw Base64 (then pick its format). The tool previews the image and lets you download it as a real file. If the string is not valid image data you will get a clear error rather than a broken image.

Does inlining an image as Base64 help page speed?

For a few tiny assets, yes — it removes extra HTTP requests. But inlined images cannot be cached separately and bloat the HTML/CSS, so for anything beyond small icons it usually hurts. A good rule of thumb is to inline assets under a few kilobytes and link everything larger.

Related tools

• Base64 Encoder / Decoder (text)
• Image Compressor
• Image Resizer
• Image to PDF

See all browser tools →