Base64 represents binary data using sixty-four printable characters, so that something which is not text can travel through a channel that only carries text — an email body, a JSON field, a data URL in a stylesheet. It is an encoding, not encryption: the transformation is public, reversible by anyone, and offers no protection whatsoever.
Text is converted to UTF-8 bytes before encoding and back again after decoding, which is what allows accented characters, other scripts and emoji to survive the round trip rather than coming back mangled. Three bytes of input become four characters of output, so anything encoded this way grows by roughly a third.
What it is for, and what it is not
-
It is not a security measure:
encoding hides nothing. Anyone can decode a base64 string in seconds, and a password or key stored this way is stored in plain sight.
-
Output is about a third larger than the input:
which matters for data URLs. Inlining a large image as base64 makes the stylesheet or document bigger than the file it replaced.
-
The URL-safe variant is a different alphabet:
tokens and URL parameters often use dash and underscore where standard base64 uses plus and slash. Those will not decode here without being converted back first.
-
Whitespace and line breaks usually survive:
many systems wrap long base64 at a fixed width. Pasted line breaks are generally tolerated by the decoder, but a truncated string is not.
What base64 is actually for
Base64 exists to let data that is not text travel through a channel built only to carry text — an email body, a JSON field, a data URL sitting inside a stylesheet. The [msm_tool slug="base64-encoder-decoder"] represents that data using sixty-four printable characters chosen specifically because every one of them survives untouched through systems that would otherwise mangle raw bytes.
An encoding, not a form of protection
The transformation is entirely public and reversible by anyone, with no key involved anywhere in the process. A password or an API key stored as base64 is not hidden in any meaningful sense — it is stored in plain sight, one decode away from being read by whoever finds it.
The output is always about a third larger
Every three bytes of input become four characters of output, which is a fixed, inherent property of the format rather than something that varies by content. That growth matters most for data URLs: inlining a large image as base64 can leave the surrounding stylesheet or document bigger than the original file it was meant to replace.
Text survives the round trip because of an extra step
Text is converted to UTF-8 bytes before encoding and converted back afterwards, which is what lets accented characters, other scripts and emoji come back exactly as they went in rather than arriving mangled. The encoding itself only ever deals in bytes; the UTF-8 conversion is what connects it back to readable text.
The URL-safe variant is a genuinely different alphabet
Tokens and URL parameters commonly use a variant where dash and underscore replace the plus and slash that standard base64 uses, specifically because plus and slash have their own meaning inside a URL. A string encoded that way will not decode correctly here without converting those characters back to the standard alphabet first.
Whitespace tolerance versus a truncated string
Many systems wrap long base64 output at a fixed line width, and those line breaks are generally tolerated when pasted back in for decoding. A string that has been cut off partway through is a different problem entirely — decoding can only work on what is actually complete.