Base64, URL encoding, hashing: which one do you need?

Base64, percent-encoding and hashing all take some text and hand you back different text. That surface similarity is why they get confused, and the confusion is expensive: people Base64 a password thinking they have protected it, or hash a value they later need to read back. The three answer completely different questions.

Base64: make binary safe to put in a text field

Base64 takes three bytes of arbitrary binary data — 24 bits — and re-expresses them as four printable characters from a 64-character alphabet. That is the whole idea. An image, a certificate or a zip file can then travel through an email body, a JSON string or an HTML attribute without anything in the pipeline mangling a byte it did not expect.

The cost is size: four characters out for every three bytes in, a fixed 33.3% overhead. The trailing = signs are padding, because the output length must be a multiple of four — one = means the last group had two bytes, two means it had one.

Use it when the channel is text-only and the data is not. Do not use it to hide anything: Base64 decoding is instant and requires no key.

Percent-encoding: make characters safe inside a URL

URLs have structure — slashes, colons, question marks, ampersands all mean something. Percent-encoding escapes any character that would otherwise be read as structure, replacing it with % and the hex value of each UTF-8 byte. A space becomes %20, an ampersand %26, and the é in "café" becomes %C3%A9 because it is two bytes.

The mistake is scope. Encode a parameter value, not the whole URL — encoding the lot escapes the very slashes and colons that make it a URL. In JavaScript that is encodeURIComponent for values and encodeURI for whole addresses; the URL encoder does the component form, which is the one you almost always want.

Hashing: prove something is unchanged

A hash is the odd one out, because it is one-way. SHA-256 turns any input, of any length, into a fixed 256-bit fingerprint — 64 hexadecimal characters. The same input always gives the same output, one changed bit gives a completely different output, and there is no computation that runs it backwards.

That makes hashes right for verifying a download, comparing two files without transferring either, and detecting tampering. It makes them wrong for anything you need to read back, and it makes a bare hash wrong for passwords — a short or common input can simply be looked up. Passwords need a purpose-built function such as bcrypt, scrypt or Argon2, with a unique salt per user.

The decision, in one line each

Need to get the original back, through a text-only channel? Base64.
Need to get it back, inside a URL? Percent-encoding.
Need to prove it has not changed, and never need it back? A hash.
Need to keep it secret from someone who has the data? None of these. Encryption.

Two traps worth naming

The first is base64url. Standard Base64 uses + and /, both of which have meaning in a URL. The base64url variant in RFC 4648 substitutes - and _ so the output can be dropped into a URL or filename unchanged — which is why JSON Web Tokens use it, and why a token pasted into a standard decoder sometimes fails.

The second is double-encoding. Encoding an already-encoded string turns %20 into %2520, and the symptom appears far downstream as a literal percent sign in a filename. If a value has passed through a framework, a proxy and a client, assume one of them has already encoded it and check before you encode again.