What this tool does
Base64 decode and encode, both directions, in the page you are reading. Paste text and get the Base64 for it; paste Base64 and get the text back. The tool reports the size on each side, because the growth is the part people forget to budget for.
Two details separate this from a one-line console snippet. First, encoding goes through UTF-8
properly, so an em dash, an accented surname or an emoji survives the round trip. Second, the
URL-safe variant is a real option rather than a search-and-replace afterthought: it swaps + and
/ for - and _ and drops the padding, which is the form you need inside a query string or a
filename.
How to use it
- Choose the direction: text to Base64, or Base64 to text.
- Paste your input on the left.
- For encoding, tick URL-safe alphabet if the result is going into a URL, a cookie or a filename.
- Copy the result, or download it as a text file.
Decoding is deliberately forgiving. It accepts both alphabets, ignores the line breaks that MIME inserts every 76 characters, and does not care whether the padding is there. Only two things are refused: a character that is not in either alphabet, and a length that no valid Base64 string can have. Both come back with the exact position or the exact reason.
What Base64 is, and what it is not
Base64 solves one problem: moving arbitrary bytes through a channel that only accepts text. Email bodies, JSON string fields, XML documents, data URIs, HTTP headers. It maps every three bytes onto four characters drawn from a 64-character alphabet that survives every ASCII-compatible system.
It is not encryption, not compression, and not obfuscation with any value. There is no key. The transformation is public and reversible by anyone, including automated scanners. A secret pasted into a Base64 string is a secret in plain sight with an extra step, and treating it otherwise is how credentials end up in logs.
Why it costs you 33% more bytes
Four characters for every three bytes is a ratio of 4:3, so the encoded form is a third larger than what went in, before padding. On a 3 MB image inlined into a data URI that is a megabyte of extra transfer, uncompressed and uncacheable separately from the document that carries it.
That is the trade-off worth stating out loud: Base64 buys you safe transport through a text-only channel and charges 33% of the payload for it. When the channel can carry bytes — a multipart upload, a binary column, a separate asset request — the charge buys nothing.
The + and / problem, and the URL-safe answer
The standard alphabet ends in + and /, and both are hostile in a URL. In a query string +
decodes as a space, so a Base64 value pasted into one silently loses a character. / is a path
separator, which breaks any value used as a path segment. = is the query separator itself.
RFC 4648 defines the URL-safe alphabet for exactly this: - replaces +, _ replaces /, and
the padding is usually omitted because it is redundant when the length is known. It is what JWTs
use in all three segments — you can watch it in the JWT decoder — and what most
token formats use for the same reason.
Decoding is where mismatched alphabets bite. A decoder that only knows the standard alphabet will
reject a URL-safe string on the first -. That is why the decoder here accepts both without asking,
and why a value you receive from an unknown source is worth pasting in before you write parsing code
around it.
Where it breaks in practice
Double encoding. A value already in Base64 encoded again looks fine and is 78% larger for nothing. If your string decodes into something that is itself valid Base64, you probably did this.
URL-encoding on top of Base64. Standard Base64 inside a URL usually gets percent-encoded as
well, so + arrives as %2B. Decoding the percent-encoding first is mandatory, and the
URL encoder and decoder is the other half of that job.
Binary treated as text. Base64 that decodes to image or archive bytes is not text, and forcing it through a UTF-8 decoder produces replacement characters rather than an error in most tools. Here it produces an error, on purpose.