URL encoding and Base64 encoding solve two different problems that happen to come up constantly in the same places: debugging a webhook payload, inspecting an API authorization header, or figuring out why a query parameter arrived garbled. Confusing the two, or using one where the other is needed, is a small but common source of integration bugs.

URL (percent) encoding

URL encoding, formally percent-encoding, escapes characters that are not safe to include literally inside a URL by replacing each one with a percent sign followed by its two-digit hex code. A space becomes %20, an ampersand becomes %26, and so on. It exists because a URL has structural characters with specific meaning, like & separating query parameters and = separating a key from its value, so any of those characters appearing literally inside a value (say, a search query that itself contains an ampersand) needs escaping to avoid being misread as part of the URL's structure rather than as data.

There are two related but different JavaScript functions worth knowing apart: encodeURIComponent escapes everything not safe in a single URL segment, including the structural characters &, = and /, which makes it the correct choice for encoding one query parameter's value. encodeURI leaves those structural characters alone, since it assumes you are encoding an entire URL rather than one piece meant to be inserted into it. Using encodeURI on a single parameter value, or encodeURIComponent on a whole URL, both produce subtly wrong results, which is a common source of confusion.

Base64 encoding

Base64 encoding converts arbitrary data, binary or text, into a string built from a 64-character alphabet (A to Z, a to z, 0 to 9, plus two more characters, conventionally + and /). It exists because many transport formats (HTTP headers, JSON, XML, email) are designed for text, not raw binary, so embedding something inherently binary (an image, a file, a cryptographic key) inside one of those formats requires first converting it to a safe text representation. Base64 is not compression and not encryption: the encoded string is roughly a third larger than the original data, and decoding it is a single reversible mechanical step, not something that requires a secret key.

Standard Base64's + and / characters both have special meaning inside a URL, so pasting raw Base64 output directly into a URL without further escaping causes exactly the kind of structural confusion URL encoding exists to prevent. URL-safe Base64 (sometimes called Base64url) sidesteps this by substituting - for + and _ for /, and by dropping the trailing = padding characters, producing a string that can be used directly inside a URL or a filename.

Debugging a webhook payload

Webhook payloads frequently include Base64-encoded fields, an attached file, an image, a signed payload for signature verification, alongside ordinary JSON fields. When a webhook handler is failing to process a payload correctly, decoding the Base64 field in isolation and inspecting the result (is it valid JSON? Is it the file type you expected? Does it match what the sender's documentation says it should contain) is usually the fastest way to tell whether the problem is in your decoding logic or somewhere else entirely.

Debugging an API auth header

HTTP Basic Authentication sends credentials as username:password, Base64 encoded, in the request's Authorization header as Authorization: Basic <encoded string>. Decoding a Basic Auth header during debugging immediately reveals whether the username and password are actually what you expect them to be, which is often faster than adding logging to the application code itself. It is worth remembering that Base64 is trivially reversible, so Basic Authentication is only considered acceptably safe when the connection itself is encrypted over HTTPS; sending it over plain HTTP exposes the credentials to anyone who can see the traffic.

Both handle full Unicode correctly, when done right
A common bug in hand-written Base64 encoding logic is mishandling non-ASCII text, accented letters, non-Latin scripts, or emoji, because Base64 is defined over bytes, not characters. Encoding through UTF-8 bytes first, rather than encoding character codes directly, is what makes international text round-trip correctly instead of becoming garbled after a decode.

Our free URL and Base64 encoder/decoder handles both directions for both encodings, includes a URL-safe Base64 option, and correctly round-trips full Unicode text by encoding through UTF-8 bytes first. It runs entirely in your browser using the browser's own built-in encoding functions; nothing you paste is uploaded or saved.