Base64 Encoder and Decoder
Both directions, UTF-8 safe, with the URL-safe alphabet when you need it.
Base64 exists because some channels only carry text. Email bodies, JSON strings, XML documents and URLs all choke on arbitrary bytes, so binary data is re-expressed using 64 characters that survive the trip. This tool converts in both directions, handles accented and non-Latin text correctly, and offers the URL-safe variant that replaces the two characters a URL would otherwise mangle.
How it works
Pick a direction
Encode plain text into Base64, or decode Base64 back to text.
Paste your input
The result updates as you type, with the size change shown underneath.
Switch alphabet if needed
The URL-safe option swaps + and / for - and _ and drops the padding.
What Base64 actually costs
The scheme reads three bytes at a time — 24 bits — and rewrites them as four characters of six bits each. Four characters carrying three bytes means the output is always about a third larger than the input, plus up to two padding characters to round the length to a multiple of four.
That overhead is the reason inlining images as data URIs is a trade-off rather than an optimisation. A 9 KB icon becomes 12 KB of CSS, and unlike a separate file it cannot be cached independently, so every visitor downloads it again with each stylesheet change. Below roughly 2 KB the saved request usually wins; above it, rarely.
Encoding text adds a step before that arithmetic. Base64 encodes bytes, not characters, so the text must first be turned into bytes — and the choice of encoding changes the result. This tool uses UTF-8, where ASCII costs one byte per character while accented, Greek, Cyrillic or CJK characters cost two to four. The byte counter under the result shows the real input size, which is why the same number of characters can produce noticeably different output lengths.
Base64 is not encryption, and the URL-safe variant exists for a reason
Anyone can decode Base64 — that is the entire point, and it takes one function call. It hides nothing. A password, an API key or a token stored Base64-encoded in a config file is stored in plain text with an extra step. The encoding of the credentials in HTTP Basic authentication is Base64 precisely because it is meant to be reversible; the confidentiality there comes from TLS, not from the encoding.
The standard alphabet ends with + and /, both of which mean something else in a URL: a plus is decoded as a space in query strings, and a slash is a path separator. Padding with = causes its own trouble in query parameters. RFC 4648 therefore defines a URL-safe variant using - and _ with padding omitted, and that is what JSON Web Tokens use for every one of their three segments.
Decoding is where the two variants meet. A decoder expecting the standard alphabet will fail or produce nonsense on URL-safe input, which is a common cause of "invalid Base64" errors in code that looks correct. This tool restores the substituted characters and re-adds missing padding when the URL-safe box is ticked, so both forms decode cleanly.