How to Convert a File to a Base64 Data URI (and Back)

A Base64 data URI packs an entire file into a single line of text — data:<mime-type>;base64,<data> — so you can drop it straight into HTML, CSS or JSON with no separate file request. Converting a file to that form means encoding its raw bytes as Base64; converting back means decoding the Base64 into bytes and saving them. Do both in your browser with the File to Base64 encoder and the Base64 to File decoder — the file never leaves your device.

What Base64 actually does

Computers store files as bytes, but many formats — JSON, HTML attributes, CSS, email — expect text. Base64 bridges that gap. It takes every 3 bytes (24 bits) and rewrites them as 4 characters from a fixed 64-symbol alphabet (A–Z, a–z, 0–9, +, /), padding the end with = when needed. The result is pure text that survives anywhere text is allowed — and it’s perfectly reversible.

Two things follow immediately:

• It’s bigger, not smaller. 3 bytes → 4 characters is a fixed 33% size increase. Base64 is not compression.
• It’s not secret. Anyone can decode Base64 instantly. It is not encryption.

A worked example, one group of 3 bytes

The clearest way to see the mapping is to encode a short piece of text by hand. Take the three characters Man. In a file these are three bytes — the ASCII codes 77, 97 and 110:

Character	Decimal	8-bit binary
M	77	01001101
a	97	01100001
n	110	01101110

Line those 24 bits up and re-slice them into four groups of 6 bits instead of three groups of 8:

01001101 01100001 01101110   ← three 8-bit bytes
010011 010110 000101 101110  ← four 6-bit groups = 19, 22, 5, 46

Each 6-bit value (0–63) is an index into the 64-character alphabet, giving T, W, F, u. So Man encodes to TWFu — three input bytes, four output characters, exactly the 4/3 ratio.

Padding handles inputs that are not a multiple of 3 bytes. A single M (one byte) has only enough bits for two Base64 characters, so the encoder emits TQ==; two bytes emit three characters plus one =. The = signs are pure length bookkeeping — they tell a decoder how many real bytes the final group holds. Binary files work identically; text just makes the digits easy to read.

From Base64 to a data URI

Raw Base64 is just the encoded text. A data URI wraps it with enough metadata that a browser can treat it as a real file:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA…
│    │         │      │
│    │         │      └─ the Base64-encoded bytes
│    │         └─ ";base64" — the data is Base64, not URL-encoded text
│    └─ the MIME type (image/png, application/pdf, font/woff2, …)
└─ the "data:" scheme

Because the MIME type travels inside the URI, the browser knows exactly what the bytes are. That’s why you can use a data URI anywhere a URL is expected:

<img src="data:image/png;base64,iVBORw0KGgo…">

.logo { background: url("data:image/svg+xml;base64,PHN2Zy…"); }

→

BASE64 3 bytes → 4 chars +33% size

→

DATA URI data:image/png;base64, iVBORw0KGgo… Embed in HTML / CSS / JSON — no separate request Decode the Base64 back to bytes to get the exact original file

Base64 is reversible text encoding — not compression, not encryption

When a data URI is the right call

Inlining an asset removes one HTTP request, which can be worth it for small, stable assets:

Good fit	Poor fit
A tiny logo in an HTML email	A large hero photo
An icon inside a CSS file	Anything you want cached on its own
A small image embedded in a JSON API response	Frequently-changing media
A font subset inlined to avoid a flash	Big PDFs or video

The reasons not to over-use it are the flip side of how Base64 works: the 33% size penalty, the fact that inlined data can’t be cached separately from the document, and the way huge data URIs bloat your HTML or CSS. As a rule of thumb, inline only assets of a few kilobytes.

How Base64 compares to the alternatives

Base64 is one of several ways to move a binary file through a text-only channel or to reference it from a document. Which one fits depends on whether you need the bytes inline and how big they are:

Approach	Inline in the document?	Size vs original	Cached separately?	Best for
Base64 data URI	Yes	~+33%	No	Small, stable assets you want in one request
Normal file + URL	No (separate request)	Same	Yes	Anything medium or large, or reused across pages
URL / percent-encoding	Yes (for text)	Varies	No	Encoding text for URLs, not arbitrary binary
svg+xml data URI (unencoded)	Yes	~same (text SVG)	No	Inlining SVG markup without the Base64 penalty

Two nuances are worth calling out. First, SVG is already text, so you can inline it in a data URI as URL-encoded markup (data:image/svg+xml,...) and skip the 33% Base64 overhead entirely — Base64 is only mandatory for genuinely binary formats like PNG, WOFF2 or PDF. Second, a plain file URL wins the moment an asset is reused across pages or changes often, because the browser can cache it once and reuse it, whereas an inlined copy is re-downloaded with every document that embeds it.

Where you actually meet Base64

You rarely type Base64 by hand, but it turns up constantly once you know the shape:

• HTML email, where many clients block external images, so a small inlined logo renders reliably.
• CSS, where a tiny icon or gradient texture is embedded with url("data:...") to cut a request.
• JSON and REST APIs, which are text formats — a binary field (an avatar, a document) is carried as a Base64 string because raw bytes cannot live in JSON.
• Data-URI favicons and SVGs in single-file HTML pages that must work with no external assets.
• Config and token formats such as JWTs, which use a URL-safe Base64 variant for each segment.

In every case the job is the same: let binary bytes ride safely inside a text container.

Decoding a data URI back to a file

Going the other way is just as mechanical. Given data:application/pdf;base64,JVBERi0…, a decoder:

1. Reads the MIME type (application/pdf) from the prefix.
2. Strips the data:…;base64, header.
3. Decodes the remaining Base64 back into the original bytes.
4. Saves them — here, as a .pdf.

Paste either a full data URI or just the raw Base64 into the Base64 to File decoder; if it’s a data URI, the MIME type is detected for you, and if it’s raw Base64 you simply choose a file name with the correct extension. Line breaks in the pasted text are ignored, so multi-line blocks work.

Why doing it in the browser matters

The files people Base64-encode are often not throwaway test images — they’re documents, signatures, internal assets. A “convert to Base64” site that uploads your file to a server has seen that content. The encoder and decoder here use the browser’s File API and run entirely on your device: nothing is transmitted, and both work offline.

The bottom line

Converting a file to Base64 turns its bytes into text; wrapping that as data:<mime>;base64,<data> makes it an inline, self-describing file you can embed anywhere a URL goes. It’s reversible, it’s not encryption, and it’s ~33% larger — so reach for it on small assets to save a request, and decode it back whenever a Base64 blob is really a file in disguise.