Base64 makes binary data safe for text-oriented transports. It does not hide data from anyone who can read the encoded text, and it does not provide integrity, authenticity, or authorization.
Start with bytes
RFC 4648 defines Base64 in terms of octets. Text therefore needs a character encoding—normally UTF-8—before Base64 encoding. Using APIs that interpret JavaScript strings as Latin-1 can fail or corrupt characters outside that range.
For the text ✓ ready, a reliable sequence is:
- Encode the Unicode string as UTF-8 bytes.
- Encode those bytes using the chosen Base64 alphabet.
- On decode, reverse Base64 to bytes.
- Decode the bytes as UTF-8 with explicit error handling.
Always compare the recovered bytes or text with the original.
Standard Base64 and base64url are different profiles
Standard Base64 uses + and /. The URL- and filename-safe alphabet replaces them with - and _. Protocols that use base64url, including compact JOSE structures, may omit trailing = padding when their specification permits it.
Do not guess the variant solely from length; many strings contain only characters shared by both alphabets. Let the surrounding protocol select the variant, and reject characters outside it.
Be explicit about padding and whitespace
RFC 4648 requires padding in the general case unless a referring specification says otherwise. Some decoders accept missing padding, inserted whitespace, or non-alphabet characters. That convenience can create interoperability differences and can hide corrupted input.
A validator should expose whether it normalized input. For protocol-critical values, use a strict decoder that follows the profile in use and rejects unexpected characters.
Decoding is not validation of meaning
Successful decoding proves only that the text could be interpreted under a Base64 profile. The bytes may still be truncated, malicious, encrypted under an unknown key, compressed to an unexpectedly large output, or mislabeled with the wrong media type.
For uploaded or untrusted data, limit encoded and decoded size before previewing. Detect the actual file type from trusted parsing rather than a user-controlled data: URL label.
Security boundary
Never store a password, API key, private key, session token, or personal record in Base64 and describe it as protected. Secrets need appropriate encryption in transit and at rest, plus access control and rotation. Signed data needs a verified signature or MAC. Passwords need a dedicated password-hashing construction.