Base64 Encoder / Decoder
Base64 exists so binary data can travel through channels that only reliably carry text. It shows up in JWTs, data URLs, HTTP Basic auth headers, email attachments, and Kubernetes secrets. It is an encoding, and the recurring mistake is treating it as protection.
How to use it
- Paste text into the input.
- Both the encoded and decoded interpretations are computed at once, so you do not have to pick a direction.
- Copy whichever you need. Nothing is transmitted.
How the encoding works
Three input bytes, 24 bits, are re-expressed as four characters from a 64-character alphabet at six bits each. Four output characters per three input bytes is exactly where the familiar 33 percent size increase comes from.
When the input length is not a multiple of three, the final group is padded with one or two equals signs so the output length stays a multiple of four. The padding carries no data; it only marks where the stream ends. Some contexts, including JWTs, drop it entirely.
It is not encryption, and this causes real breaches
There is no key and no computational cost to reversing Base64. Anyone holding the encoded string has the original data.
The confusion is common enough to be a recognised source of incidents. Kubernetes secrets are Base64-encoded in their YAML representation, and the encoding is there so that binary values can live in a text field, not to protect anything. Anyone with read access to the resource has the plaintext. The same applies to HTTP Basic authentication, where the credentials are Base64 of username:password and are protected only by TLS.
If a value needs to stay confidential, encrypt it. Base64 is transport encoding.
Base64url, and why your decode is failing
Standard Base64 uses plus and slash as its last two alphabet characters. Both are hostile in URLs: plus is interpreted as a space in query strings, and slash is a path separator.
RFC 4648 defines a URL-safe variant that substitutes hyphen and underscore, and usually omits the padding. JWTs use it, as do many token formats and file-safe encodings.
When a decode fails on a value taken from a URL, a JWT, or a filename, this is nearly always why. Replace hyphen with plus, underscore with slash, then append equals signs until the length is a multiple of four, and it will decode.
The Unicode trap
The browser btoa function operates on Latin-1 and throws an InvalidCharacterError on any character above U+00FF. Emoji, accented characters, and every non-Latin script hit this, which is why so many hand-rolled Base64 helpers break the first time a user with a non-English name uses them.
The fix is to convert text to UTF-8 bytes before encoding, and back through UTF-8 after decoding. That is what happens here, so the round trip is safe for arbitrary Unicode.
Line wrapping
MIME requires a line break every 76 characters, which is why Base64 pulled out of an email source or a PEM certificate arrives as a block of short lines. Strict decoders reject the embedded whitespace.
Output here is a single unbroken line, and the decoder ignores whitespace in its input, so a pasted PEM body decodes without needing to be joined up first.
At a glance
| Alphabet | Standard RFC 4648 with padding |
|---|---|
| Text encoding | UTF-8, so all Unicode round-trips |
| Whitespace | Ignored on decode |
| Size change | Plus roughly 33 percent when encoding |
Frequently asked questions
Does Base64 protect my data?
No. It is a reversible encoding with no key. Kubernetes secrets and HTTP Basic auth are both Base64 and neither is protected by it.
Why will my JWT segment not decode?
JWTs use Base64url, which swaps plus and slash for hyphen and underscore and drops padding. Reverse the substitutions and add equals signs until the length is a multiple of four.
Does it handle emoji and non-Latin text?
Yes. Text is converted to UTF-8 before encoding, which avoids the character range error the raw browser API throws above U+00FF.
Why is the encoded string longer than the input?
Four output characters represent every three input bytes, so encoded data is about a third larger. That is inherent to the format.
Read more
Formatting and encoding — Pretty-printing catches bugs, Base64 costs 33 percent, and escaping applied in the wrong context prevents nothing.