Base64 encodes binary data into ASCII text; URL encoding (percent-encoding) makes text safe to put inside a URL. They're not interchangeable, and mixing them up is a common source of "why is this string broken" bugs — especially once a Base64 string ends up inside a query parameter.
What Base64 actually does
Base64 takes arbitrary bytes and maps them to a 64-character alphabet (A–Z, a–z, 0–9, +, /), padded with =. It's used to safely embed binary data — images, file contents, tokens — inside text-based formats like JSON, HTML, or email. A Base64 Encoder/Decoder handles this conversion in either direction.
The problem: +, /, and = all have special meaning in a URL. + means "space" in a query string, / looks like a path separator, and = separates keys from values. Drop standard Base64 output straight into a URL and you'll get silently corrupted data.
What URL encoding actually does
URL encoding (RFC 3986 percent-encoding) escapes any character that isn't valid in a URL component by replacing it with % followed by its hex byte value — a space becomes %20, & becomes %26, and so on. A URL Encoder/Decoder does this for query strings, path segments, or full URLs.
It's not a general binary-to-text scheme — it's specifically about making a string safe inside a URL.
The two side by side
| | Base64 | URL Encoding |
|---|---|---|
| Purpose | Binary → text | Text → URL-safe text |
| Output alphabet | A-Z a-z 0-9 + / = | Original chars + %XX escapes |
| Typical use | Embedding files/tokens in JSON, HTML, headers | Query strings, path segments |
| Breaks in a URL? | Yes — + / = collide with URL syntax | No — that's its whole job |
| Reversible? | Yes, exactly | Yes, exactly |
Where they intersect: Base64URL
This is where most real bugs come from. JWTs, for example, use Base64URL — a Base64 variant that swaps + → - and / → _, and usually drops the = padding entirely, so the output is safe to use directly in a URL or filename without a second encoding pass. Standard Base64 and Base64URL look almost identical and are easy to confuse until a token with a + in it silently breaks in production.
When to use which
- Embedding a file, image, or binary blob in JSON/HTML → Base64
- Putting a value inside a URL query string → URL encoding
- Putting a Base64 string inside a URL → re-encode it as Base64URL, or URL-encode the standard Base64 output — don't paste it raw
- Decoding a JWT segment → Base64URL decode, not standard Base64 (a JWT Decoder handles this automatically)
Quick checklist
- If your data is binary → start with Base64
- If your data is going into a URL → URL-encode it, or use Base64URL if it's already Base64
- If a Base64 string "breaks" only when it's part of a link, check for
+,/, or= - Never assume Base64 output is URL-safe by default — it isn't