Image to Base64

Base64 is a way of representing arbitrary binary data — like the bytes that make up a JPEG or PNG file — using only 64 printable, plain-text characters (A-Z, a-z, 0-9, plus two extra symbols, typically + and /). It exists because many systems and formats were built to carry text safely but not raw binary bytes: email, older configuration file formats, JSON, CSS, and HTML attributes can all reliably contain a Base64 string, whereas embedding raw binary bytes directly into those same contexts risks corruption, encoding mismatches, or outright breaking the surrounding format. Base64 solves this by mapping every 3 bytes of binary input to exactly 4 text characters, so any binary payload — including an entire image file — can be represented as a plain string that safely survives being copied, pasted, stored in a database text column, or embedded directly inside another text-based file. The most common practical use for a Base64-encoded image on the web is embedding it directly inside HTML or CSS without a separate file request: an `<img src="data:image/png;base64,iVBORw0KG...">` tag or a CSS `background-image: url(data:image/png;base64,...)` declaration renders the image immediately from the encoded text itself, with no additional network round-trip needed to fetch a separate image file. This is genuinely useful for very small images — icons, tiny logos, a handful of UI decorations — where the overhead of a separate HTTP request would outweigh the benefit, or for contexts where a single self-contained file (an email, a generated PDF, an offline document) needs to include an image without any external dependency at all. It comes with a real trade-off, though: because of that 3-bytes-to-4-characters expansion, a Base64-encoded image is always roughly 33% larger than the original binary file, and unlike a normal image file referenced by URL, an embedded data URI can never be cached separately by the browser — it's re-downloaded and re-parsed every single time the surrounding HTML or CSS document loads, however large it is. For anything beyond a small icon, a normal image file reference almost always performs better. The distinction between the full data URI and the raw Base64 string matters because different contexts expect different things. The full `data:image/png;base64,...` form is what browsers, `<img>` tags, and CSS expect directly — the `data:image/<type>;base64,` prefix tells the parser exactly how to interpret the text that follows. Plenty of other contexts, though — a database column storing just the encoded bytes, an API that reconstructs the data URI itself from a separate stored MIME type, or a backend language's own Base64-decoding function — expect only the raw encoded string with no prefix at all, and would either fail to decode correctly or store an unwanted extra prefix if handed the full data URI by mistake. Having both readily available side by side removes the need to manually strip or reconstruct the prefix by hand. Everything in this tool happens using the browser's built-in `FileReader.readAsDataURL()` method, which reads the file you choose and produces the full data URI directly — no image data is ever transmitted to a server in the process.