Base64 File Converter

How to use this Base64 file converter

1. To encode: choose any file — it converts to a Base64 string automatically.
2. To decode: paste a Base64 data URI (starting with "data:") into the text box.
3. Click "Decode & Download File" to reconstruct and save the original file.

How does decoding work?

Paste a Base64 data URI (starting with "data:") into the text area and click download to reconstruct the original file — everything happens locally in your browser.

How Base64 encoding actually works

Base64 exists to represent arbitrary binary data — the raw bytes of an image, a PDF, a ZIP file — using only 64 characters that are safe to put inside plain text: A–Z, a–z, 0–9, plus two more symbols (+ and /, or - and _ in the URL-safe variant). The encoding works by taking three bytes of input (24 bits total) and repacking them into four 6-bit groups, each mapped to one character from that 64-character alphabet. When the input's length isn't a multiple of three, the output is padded with one or two = characters at the end, which is why you'll sometimes see a Base64 string ending in one or two equals signs and sometimes none at all.

Why the size overhead is unavoidable

Every three bytes of input become exactly four characters of output, which is where the roughly 33% size increase comes from — encoding 3 MB of binary data produces about 4 MB of Base64 text. This isn't an inefficiency that could be optimized away; it's the direct mathematical consequence of representing 8-bit bytes using only 6 bits of information per output character, since the alphabet is restricted to something that's safe to embed in text-only formats. If file size is the priority and the destination can handle raw binary (an HTTP file upload, for instance), Base64 is the wrong choice — it exists specifically for contexts where binary data has to travel through a text-only channel, not as a general-purpose compression or transfer format.

When Base64 is the right tool

Base64 earns its overhead in specific situations: embedding a small icon directly inside a CSS file or HTML page as a data URI (avoiding an extra HTTP request for a tiny image), attaching a file to an email (the MIME standard requires attachments to be text-encoded), or storing binary data inside a JSON payload, which has no native binary type. It's a poor choice for large files or for anything where an actual binary transfer channel is available — uploading a multi-megabyte video as Base64 inside a JSON API call, for example, wastes a third more bandwidth than sending the same file as raw binary through a proper file upload endpoint.

A common mistake: mixing up Base64 variants

Not all Base64 is identical. Standard Base64 uses + and / in its alphabet, but both of those characters have special meaning inside a URL, so a "URL-safe" variant replaces them with - and _ instead — a string encoded in one variant will fail to decode correctly (or throw an "invalid character" error) if you feed it into a decoder expecting the other. Email's MIME standard adds another wrinkle: it wraps encoded output at 76 characters per line for compatibility with old mail systems, while most modern APIs and data URIs expect Base64 as one continuous line with no line breaks at all. If a decode fails with an unexpected result, checking which variant and formatting convention the source actually used is usually the fix.

Limitations of this tool

This converter runs entirely in your browser's memory, so very large files (several hundred MB or more) may be slow to process or exceed what the browser can hold — there's no server-side fallback, by design, since nothing about your file is ever meant to leave your device. It expects a standard Base64 data URI (starting with "data:") for decoding, and doesn't automatically detect or convert between the standard and URL-safe alphabets — if a pasted string uses - and _ instead of + and /, it will need to be converted to the standard alphabet first for this tool to decode it correctly.