Base64 Is Not Encryption: What It Is Actually For

Base64 is an encoding, not encryption. Anyone can turn it back into the original. There is no key and the conversion rule is public: switch Base64 Encode & Decode to Decode, put in WkVLSUxP, and you get ZEKILO right away. Converting a password or a token to Base64 does not hide it. What Base64 is for is carrying binary data intact through channels that only accept text.

What Base64 does

According to RFC 4648, Base64 takes the input three bytes (24 bits) at a time, splits them into four 6-bit groups and writes each group as one character. The alphabet has 64 characters, A–Z, a–z, 0–9, + and /, plus = for padding.

Input	Bytes	Base64
ZEKILO	6	WkVLSUxP
ZEKIL	5	WkVLSUw=
제킬로	9 (UTF-8)	7KCc7YKs66Gc
ゼキロ	9 (UTF-8)	44K844Kt44Ot

Base64 works on bytes, not on characters. Text is first turned into bytes with a character encoding such as UTF-8, so a different character encoding gives a different result. The browser function btoa throws an InvalidCharacterError when the string contains a character above U+00FF. For Korean, Japanese or emoji, create the UTF-8 bytes with TextEncoder first and encode those.

Encoding, encryption and hashing

Kind	Can it be reversed?	Key	Purpose
Encoding (Base64)	Yes, by anyone	None	Change the format
Encryption (AES, etc.)	Only with the key	Yes	Keep the content private
Hashing (SHA-256, etc.)	No, it is one-way	None	Check that content is the same

Section 12 of RFC 4648 says that base encoding visually hides otherwise easily recognized information, such as passwords, but does not provide any computational confidentiality.

HTTP Basic authentication is the classic example. Decode the last part of the example header in RFC 7617, Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==, and you get Aladdin:open sesame: the user name and the password as they are. The same document states that the scheme is not considered a secure method of user authentication unless it is used together with an external secure system such as TLS. The header and payload of a JWT are also just Base64URL text that anyone can read; see decoding a JWT vs verifying it for details.

When Base64 is the right tool

• Email attachments (MIME): the encoded text is split into lines of no more than 76 characters (RFC 2045).
• Data URLs: a small file is placed directly inside HTML or CSS, as in data:text/plain;base64,WkVLSUxP (RFC 2397).
• JSON and XML fields: binary data such as an image or a signature value is carried in a text field.
• PEM certificates and keys: lines are wrapped at 64 characters (RFC 7468).
• JWTs and URL parameters: these use the URL-safe variant described below.

RFC 4648 says implementations must not add line feeds unless the specification that refers to it tells them to. Whether you need line breaks depends on the format the receiver expects.

The URL-safe variant and padding

Two characters of the standard alphabet, + and /, have another meaning in URLs and file names. Section 5 of RFC 4648 therefore defines a variant that replaces them with - and _. The bytes FB FF BF are +/+/ in the standard alphabet and -_-_ in the URL-safe one.

The padding character = makes the output length a multiple of four. If one byte is left over at the end, the output ends with two characters and ==; if two bytes are left over, it ends with three characters and =. RFC 4648 requires padding unless the referring specification says otherwise, and the Base64URL used by JWTs (RFC 7515) omits it. The data can still be recovered from the length, so WkVLSUw decodes to ZEKIL. A length that leaves a remainder of 1 when divided by 4 is never valid Base64.

When decoding fails, check the characters first. WkVLSUxP! is rejected because the 9th character, !, is not in the Base64 alphabet.

The size grows by 4/3

Three bytes become four characters, so the padded output length is 4 × ⌈n ÷ 3⌉ for n bytes. That is about 33% more.

Original	Base64 length
6 bytes	8 characters
9 bytes	12 characters
1 MiB (1,048,576 bytes)	1,398,104 characters
3 MiB (3,145,728 bytes)	4,194,304 characters (4 MiB)

Line breaks add a little more on top. Putting a large file into JSON as Base64 increases both the transfer size and the memory needed to handle it, so for large files first consider sending the binary data as it is.

Summary

• Base64 is an encoding that changes the format. It has no key, so it cannot keep anything private.
• Passwords, API keys and personal data are fully exposed in Base64. To protect them, use encryption and TLS.
• For URLs and JWTs use the URL-safe variant with - and _, and follow the receiver’s rule for padding.
• The result is about 4/3 of the original size.
• To check a value, use Base64 Encode & Decode. Your input is processed only in your browser.