Base64 vs URL Encoding: What's the Difference?
Base64 and URL encoding (percent-encoding) are both ways to represent data safely for transmission, and they are frequently mixed up. They solve genuinely different problems: Base64 converts binary data into a text-safe alphabet, while URL encoding escapes characters that have special meaning inside a URL. Knowing which to apply — and in what order — prevents a whole class of subtle bugs.
| 方面 | Base64 Encoding | URL (Percent) Encoding |
|---|---|---|
| Problem it solves | Make binary data text-safe | Make text safe inside a URL |
| Output alphabet | A–Z, a–z, 0–9, + / | Original chars + %XX escapes |
| Size change | +33% larger | Varies — only unsafe chars grow |
| Typical use | Images in HTML, Basic Auth, JWT | Query parameters, form data |
| Space becomes | Encoded as part of binary | %20 (or + in form encoding) |
| Reversible without a key | Yes | Yes |
| URL-safe by default | No (+ and / are unsafe) | Yes — that is its purpose |
Base64: Binary-to-Text
Base64 exists to move binary data through channels that only accept text. It maps every 3 bytes of input to 4 printable ASCII characters, which is why output is about 33% larger than the input. It is used to embed images in HTML as data URIs, to encode credentials for HTTP Basic Authentication, and to carry the header and payload of a JWT.
Base64 is not encryption. Any Base64 string can be decoded back to the original data instantly, so it provides no confidentiality — only compatibility.
URL Encoding: Escaping Reserved Characters
URL encoding escapes characters that carry structural meaning in a URL — like &, =, ?, /, and space — so they are treated as literal data rather than URL syntax. A search for "C# & .NET" must become "C%23%20%26%20.NET" in a query parameter, or the & would be misread as a separator between parameters.
Unlike Base64, URL encoding only changes the unsafe characters; safe characters (letters, digits, and - _ . ~) pass through untouched, so the size increase depends entirely on how many special characters the input contains.
When You Need Both (and the Order Matters)
A common pattern is to Base64-encode binary data and then put it in a URL. Standard Base64 uses + and /, which are unsafe in URLs — so you must either URL-encode the Base64 string or use Base64URL, a variant that replaces + with - and / with _. JWTs use Base64URL precisely so tokens can sit in URLs and headers without further escaping.
The rule of thumb: Base64 first to make binary text-safe, then URL-encode (or use Base64URL) to make that text URL-safe. Doing it in the wrong order, or skipping the URL step, is a frequent source of "works locally, breaks in the browser" bugs.
常见问题
Is Base64 the same as URL encoding?
No. Base64 converts binary data into a 64-character text alphabet; URL encoding escapes reserved characters within text so they are safe inside a URL. They solve different problems and produce very different output for the same input.
What is Base64URL and how is it different?
Base64URL is a URL-safe variant of Base64 that replaces + with - and / with _, and usually drops the = padding. It lets a Base64 string sit in a URL path, query string, or filename without further percent-encoding. JWTs and many OAuth tokens use Base64URL.
Why does Base64 make data bigger but URL encoding sometimes does not?
Base64 always expands data by about 33% because it maps 3 bytes to 4 characters regardless of content. URL encoding only expands the specific characters that are unsafe in URLs; if your text is mostly letters and digits, the size barely changes.
If I Base64-encode data for a URL, do I still need URL encoding?
Standard Base64 uses + and /, which are unsafe in URLs, so yes — either URL-encode the Base64 output or use Base64URL instead. Base64URL is purpose-built for this and avoids the extra percent-encoding step.