URL Encoding vs Base64

Two encoding schemes, two different jobs. Here's when you need which.

The Short Version

URL encoding makes strings safe for URLs. Base64 makes binary data safe for text systems. They solve different problems, and you'll sometimes need both in the same project.

URL Encoding (Percent-Encoding)

URLs have a limited set of allowed characters. Letters, numbers, and a handful of symbols like hyphens and underscores are fine. Everything else needs to be encoded.

URL encoding replaces unsafe characters with a percent sign followed by two hex digits. A space becomes %20. An ampersand becomes %26. A forward slash becomes %2F. The original character's byte value in hex, prefixed with %.

You need URL encoding when:

• Putting user input into query parameters - ?search=hello%20world
• Passing special characters in path segments
• Encoding form data for application/x-www-form-urlencoded submissions
• Building URLs programmatically from user-supplied values

JavaScript gives you two functions: encodeURIComponent() for individual values, and encodeURI() for complete URIs. Use encodeURIComponent() almost always. The full encodeURI() version leaves characters like & and = intact, which breaks things when you're encoding parameter values.

Base64 Encoding

Base64 solves a fundamentally different problem. It takes any binary data - images, files, raw bytes - and converts it into a string of printable ASCII characters. Three bytes in, four characters out.

You need Base64 when:

• Embedding binary data in JSON payloads
• Inlining small images as data URIs in HTML or CSS
• Sending file data through text-only protocols like SMTP
• Working with JWT tokens (which use Base64url encoding)
• Encoding data for HTTP Basic Authentication headers

JavaScript has btoa() and atob() for Base64, though they only handle Latin-1 characters. For Unicode or binary data, you'll need the TextEncoder API or a library.

The Overlap

Here's where it gets confusing. Sometimes Base64 strings end up inside URLs. A JWT in a query parameter, for instance. Standard Base64 uses +, /, and = - all of which have special meaning in URLs.

This is why Base64url exists. It swaps + for - and / for _, and often drops the padding =. JWTs use Base64url for exactly this reason.

If you're putting standard Base64 into a URL without using the URL-safe variant, you need to URL-encode the Base64 string too. That means double encoding - the data gets Base64-encoded first, then the Base64 output gets URL-encoded. This is correct but confusing to debug.

Side-by-Side Comparison

Purpose: URL encoding makes text URL-safe. Base64 makes binary text-safe.

Size impact: URL encoding varies - most ASCII text stays the same size, but non-ASCII characters grow. Base64 always adds 33% overhead.

Reversibility: Both are fully reversible. Neither provides security.

Character set: URL encoding uses the original characters plus percent-encoded sequences. Base64 uses A-Z, a-z, 0-9, +, /, and = (or the URL-safe variant).

Use case test: If you're dealing with text that needs to go in a URL, use URL encoding. If you're dealing with binary data that needs to travel through a text channel, use Base64.

Common Pitfalls

Encoding the wrong thing. Don't Base64-encode query parameter values when URL encoding is what you need. Base64 adds overhead for no benefit if your data is already text.

Forgetting to decode. Double-check that you're decoding in the right order. If data was Base64-encoded and then URL-encoded, you need to URL-decode first, then Base64-decode.

Mixing up JavaScript functions. encodeURIComponent() is for URL encoding. btoa() is for Base64. Don't swap them.

Try Both

← Back to all tools