Base64, hex and URL-safe encodings of binary data

What it is

RFC 4648 defines Base16 (hex), Base32 and Base64 plus the URL- and filename-safe Base64 variant that uses - and _ instead of + and /. Base64 encodes every 3 bytes as 4 characters and pads with = to a multiple of four; decoders differ in whether they require the padding.

Why it matters

Tokens, keys, signatures and hashes travel through JSON, headers, URLs and file names that cannot carry raw bytes. Choosing the wrong alphabet produces characters that URL-encoding mangles; mismatched padding rules produce decode errors between systems.

How to apply

• Use URL-safe Base64 without padding for tokens in URLs and headers, and document that choice; add padding back before decoding if the library needs it.
• Use hex where humans read or type the value (fingerprints, short identifiers); it is longer but unambiguous.
• Keep encoders and decoders strict: reject characters outside the alphabet and non-canonical encodings when the value is security relevant.
• Never treat encoding as protection; anyone can decode it.

Pitfalls

Concatenating Base64 strings does not concatenate the bytes. Line breaks inserted by some encoders (MIME) break strict decoders. Comparing encoded secrets with == leaks timing; decode and use a constant-time comparison.