Base64 encode & decode, without uploading

How it works

1. To encode, drop a file and copy the Base64 or data: URI it produces.
2. To decode, paste Base64 text or a data: URI and download the file.
3. Large files are handled in chunks, so nothing freezes or overflows.

What Base64 is for

Base64 turns binary data into plain text, so a file can travel through channels that only accept text: embedded directly in HTML or CSS as a data: URI, stored in a JSON field, or pasted into an email. It is an encoding, not encryption: it adds about a third to the size and offers no privacy on its own. Doing it here keeps the underlying file on your device.

What Base64 actually is

Base64 is not compression and not encryption: it's a way of representing arbitrary binary bytes using only 64 printable characters (A–Z, a–z, 0–9, plus two more, `+` and `/`), so the result is safe to put anywhere that only guarantees plain text: an email body, a URL query string, a JSON field, an XML attribute. It works by regrouping the data 6 bits at a time instead of the usual 8, so each character carries less information than a raw byte does. The consequence is a fixed size cost: three bytes of input always become exactly four Base64 characters, so encoded text runs about 33% larger than the original file. `=` padding characters are appended at the end when the input length isn't a clean multiple of three, just to keep that 4-character grouping intact.

Data URIs and where they help

Turning on the data-URI option wraps the same Base64 payload in a `data:<mime-type>;base64,<data>` prefix — a self-contained string you can drop straight into an `src`, a CSS `background-image`, or a JSON config value, with no separate file and no extra network request. That's genuinely useful for small, fixed assets like an inline icon or a tiny placeholder image, where saving a request is worth the 33% size penalty. It stops paying off for anything large: a big image embedded this way is not only bigger over the wire than the original file, it also can't be cached independently by the browser the way a linked file can.

The URL-safe variant, and other gotchas

Standard Base64's `+` and `/` characters both have special meaning inside a URL, so some systems (including URL query parameters and JSON Web Tokens) use a URL-safe alphabet instead, swapping `+` for `-` and `/` for `_`, and often dropping the trailing `=` padding altogether since it's redundant when you know the original length. Morphr's decoder accepts both forms automatically, along with Base64 that's been wrapped over multiple lines (common when it's pasted out of an email or a source file, since older tools inserted line breaks every 76 characters). The encoder here, however, always produces the standard alphabet with padding — if a service specifically needs the URL-safe form, you'll need to substitute the two characters yourself afterward.

One classic pitfall this tool sidesteps: the browser's native `btoa`/`atob` functions only understand single-byte characters, so calling `btoa()` directly on a JavaScript string containing non-Latin text (emoji, accented letters, CJK characters) throws or corrupts the data. Morphr encodes the raw bytes of the file you drop (read as bytes from the start, never as a JavaScript text string), so this doesn't come up here regardless of what language or script the file's contents are in.

Why this is not privacy or security

Because the alphabet and the grouping rule are both fixed and public, decoding Base64 requires no key or password: anyone, including any tool on the internet, can turn it straight back into the original bytes. Systems sometimes use Base64 to make binary data look opaque, which occasionally gets mistaken for protection; it isn't one. If what you actually need is for a file to be unreadable without a secret, that's a job for the /encrypt tool, which uses real authenticated encryption instead.

When encoding to Base64 is genuinely the right tool

Outside of data URIs, Base64 shows up constantly in day-to-day debugging: an API that returns a file as a Base64 string in a JSON response, a webhook payload that arrives Base64-encoded, an environment variable or CI secret that has to be plain text, or a JWT whose header and payload segments are themselves Base64url, so decoding one to inspect its claims is a one-paste operation here. On the encode side, dropping a binary file straight in and copying the text out is faster than reaching for a command-line tool when you just need to paste a value into a config file or a support ticket.