Can I encode large images?

Technically yes, but don't. Base64 adds 33% (1 MB → 1.33 MB) and you lose browser caching. Use this for ~10 KB or smaller.

SVG is text — URL encoding can be smaller than Base64 (`data:image/svg+xml, `). Some environments (CSS background-image) prefer Base64 for safety.

Is the file uploaded anywhere?

No. Files are read with FileReader in the browser only — nothing leaves your device.

Example

icon.png (4.2 KB, 32×32)

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACAAAAAg...

Inline-friendly in HTML / CSS / Markdown. Base64 inflates size by ~33%, so this is best for small images (or SVG handled separately).

Usage / FAQ

Q.Can I encode large images?: A.Technically yes, but don't. Base64 adds 33% (1 MB → 1.33 MB) and you lose browser caching. Use this for ~10 KB or smaller.
Q.What about SVG?: A.SVG is text — URL encoding can be smaller than Base64 (`data:image/svg+xml,<svg ...>`). Some environments (CSS background-image) prefer Base64 for safety.
Q.Is the file uploaded anywhere?: A.No. Files are read with FileReader in the browser only — nothing leaves your device.

Fun facts

The `data:` URI scheme was standardized in 1998 as RFC 2397. Forms like `data:image/png;base64,iVBOR...` let you inline small images directly inside HTML or CSS — no separate HTTP request needed.
RFC 2397 (1998)
The size cost of base64 inlining — encoded data grows by about 33% (3 bytes → 4 ASCII characters). A 5 KB PNG becomes a ~6.7 KB data URI, and it can't be cached separately (it's part of the HTML). For larger images, a separate file is dramatically more efficient.
Wikipedia — Data URI
Inlining was valuable in the HTTP/1.1 era as a request-saving trick — but HTTP/2 multiplexing eroded that benefit. The current guidance is: only inline tiny icons (< 1 KB) and keep everything else as separate files, so caching, gzip, and HTTP/2 push can do their work.
MDN — data URI scheme