Base64, URL Encoding, and HTML Entities: When Each One Is Used
Base64, percent-encoding (often called URL encoding), and HTML entities all take text that would cause a problem in some context and rewrite it into a safe form. They are easy to confuse because the output often looks similarly scrambled. They solve different problems and are not interchangeable.
Base64 — "Hi"
Encoded
Percent-encoding — a space
Encoded
HTML entity — an ampersand
Encoded
Base64: binary through a text-only channel
Base64 exists because some systems only reliably carry printable ASCII — email bodies, JSON strings, data: URLs, some HTTP headers. It takes arbitrary bytes and represents them using just 64 characters: A–Z, a–z, 0–9, +, and /, with = as padding.
It works in groups: every 3 bytes (24 bits) become 4 characters (4 × 6 bits). That is why Base64 output is always a multiple of 4 characters long, and why it is about 33% larger than the input. When the input is not a multiple of 3 bytes, the output is padded with one or two = signs.
"Hi" →SGk=
"Hello" →SGVsbG8=
Base64 is not encryption. There is no key and the transformation is public. Anyone can decode it instantly — the Base64 encoder / decoder goes both directions. Treat Base64 text as fully readable; never use it to "hide" a secret.
You will also meet base64url, a variant that swaps + and / for - and _ and often drops the padding, so the result is safe to drop into a URL or filename. JWTs use it (see below).
Percent-encoding: safe values inside a URL
A URL has a structure — ? starts the query, & separates parameters, / separates path segments, # starts the fragment. If a value in the URL contains one of those characters, or a space, or a non-ASCII character, it has to be escaped so it is not mistaken for structure. Percent-encoding replaces each such byte with % followed by its two-digit hex value.
space →%20&→%26=→%3D
"café" →caf%C3%A9(the é is two UTF-8 bytes)
Two things trip people up. First, there are different rules for path vs. query vs. form data — in application/x-www-form-urlencoded a space becomes +, but in a path it must be %20. Second, encoding an already-encoded string double-escapes it: %20 becomes %2520. The URL encoder / decoder handles component-level and full-URL encoding separately for this reason.
HTML entities: literal characters inside HTML
In HTML, < opens a tag and & opens an entity. To display those characters as text — or to show code, or to include a character you cannot type — you write an entity: an &, a name or number, and a ;.
<→ <&→ &©→ ©—→ — (numeric, decimal)—→ — (numeric, hex)
The four that matter most for safety are <, >, &, and ". Escaping those in any text that gets inserted into a page is the baseline defence against HTML injection. The HTML entity encoder / decoder converts a block of text in either direction.
Telling them apart at a glance
| You see | It's probably |
|---|---|
Long run of letters/digits ending in = or ==, length a multiple of 4 | Base64 |
% followed by two hex digits, scattered through otherwise readable text | Percent-encoding |
&word; or &#digits; | HTML entity |
| Three dot-separated Base64url chunks | A JWT — decode it with the JWT decoder |
What none of them do
None of these provide confidentiality or integrity. They are reversible by design and require no secret. If you need to protect data, that is encryption and signing — a different toolset entirely.