File → Base64 (data URI)
Pick a file, get a data: URI you can paste directly into
HTML, CSS, or anywhere a URL goes.
What you get
A data URI looks like:
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVR4XmNgYGBgAAAABQABh6FO1AAAAABJRU5ErkJggg== The MIME type is auto-detected from the file. The base64 portion is just the file's bytes encoded with the standard alphabet.
Where to paste it
- HTML:
<img src="data:image/png;base64,..."> - CSS:
background-image: url("data:image/png;base64,...") - Markdown:
 - JSON / API payloads: as a string field.
- Direct browser navigation: paste the whole URI into the address bar to view/download.
When data URIs help
- Tiny inline icons — sprites, brand marks, single-purpose UI graphics under ~5 KB. Saves an HTTP request.
- Self-contained HTML email. Inlining images means the email renders without external image-loading permission.
- Demo / fixture pages. When you don't have a stable image URL handy, inlining is the lowest-friction option.
- Generated content. Code that creates an image client-side (e.g. a chart) and offers it as a download link uses a data URI on a temporary
<a>.
When data URIs hurt
- Anything larger than ~10 KB. The 33% size penalty plus the inlining cost outweighs the saved request.
- Cache-friendly assets. Regular URLs cache; inlined data URIs don't (they're part of the parent document).
- Reused images. Inlining the same image into 50 emails or HTML pages duplicates the bytes 50 times.
- Serving large data URIs over HTTP. Most servers and CDNs don't gzip URLs, so the 33% overhead is paid in full on every request.
Decoding back to a file
Strip the data:<mime>;base64, prefix, paste the remaining
base64 into the decoder — but the result is binary
bytes, not text. To get the file back, you need code:
// JavaScript: data URI → File / Blob / download
async function dataUriToBlob(uri) {
const res = await fetch(uri);
return res.blob(); // browser handles base64 decoding for you
}
// Or, manual:
const [, prefix, b64] = uri.match(/^data:(.+?);base64,(.+)$/);
const bytes = Uint8Array.from(atob(b64), c => c.charCodeAt(0));
const blob = new Blob([bytes], { type: prefix.split(",")[0] });
const url = URL.createObjectURL(blob); // for downloading or rendering Privacy
The file is read entirely in-browser by FileReader.readAsDataURL.
No upload, no temporary file on a server. You can verify in DevTools
by watching the Network tab — picking a file produces zero
requests. The same is true if you drag-and-drop or use the file
picker. The output stays on your machine until you explicitly copy
or paste it elsewhere.
FAQ
Is my file uploaded somewhere?
No. The file is read in your browser via the FileReader API. The bytes never leave your device. Open DevTools → Network and verify — there's nothing to upload to.
What's a data URI?
A data URI embeds a file directly into a URL using the data: scheme. Format: data:<mime-type>;base64,<base64-data>. Example: data:image/png;base64,iVBORw0KGgo... can be used as the src of an <img>, the href of a download link, or in CSS background-image.
When should I use a data URI vs a regular file?
Data URIs avoid an HTTP request, which helps for tiny inline images (icons, sprites). For anything larger than ~10 KB, prefer a regular URL — data URIs bloat HTML/CSS, can't be cached separately, and parse slower than binary fetches.
How big a file can I encode?
Browsers can handle multi-MB inputs in FileReader, but encoding a 100 MB file produces a ~133 MB string that browsers struggle to render in a textarea. Practical limit: a few MB.