Home › Base64 & URL Encoder

Base64 & URL Encoder

Turn text into Base64, decode it back, or percent-encode a string so it survives inside a URL. Two encodings, one page, no upload.

Two encodings that solve different problems

Base64 and URL encoding look similar — both turn ordinary text into a string of safe-looking characters — but they exist for different reasons, and using the wrong one is a common source of bugs. Base64 exists to carry binary data through systems that only handle text. An image, a file, or a token is a sequence of bytes, and bytes can include values that email, JSON, and HTTP headers cannot represent safely. Base64 solves that by regrouping the bytes into 6-bit chunks and writing each chunk as one of 64 printable characters: A–Z, a–z, 0–9, plus + and /, with = as padding at the end. The output is about a third larger than the input, which is the price of making it text-safe. That is why you see Base64 in data URLs for small images, in JSON Web Tokens, in email attachments, and in API keys.

URL encoding — also called percent-encoding — exists for a narrower job: making a value safe inside a URL. A URL has reserved characters with special meanings. An ampersand separates query parameters, an equals sign separates a key from its value, a question mark starts the query, and a space is not allowed at all. If your value contains any of those characters, it must be encoded or the URL will be misread. Percent-encoding replaces each unsafe byte with a percent sign followed by two hex digits: a space becomes %20, an ampersand becomes %26, and an equals sign becomes %3D. Letters, digits, and a few safe punctuation marks are left alone.

The two encodings are not interchangeable. Base64 output itself contains +, /, and =, which all have meanings in a URL, so Base64 placed directly in a query string can still break — that is why a URL-safe variant of Base64 exists, swapping + and / for - and _. Use Base64 when the problem is binary data in a text channel, and URL encoding when the problem is a special character in a URL.

One more thing to know: neither encoding is encryption. Base64 is trivially reversible — anyone can decode it in a second — so it must never be used to hide a password, a secret, or anything sensitive. The same is true of URL encoding, which is reversible by design. If data needs to be secret, encrypt it first with a real encryption method, and only then encode the result for transport. The full guide, Base64 vs. URL Encoding: What Each One Is For, goes deeper into both encodings, the URL-safe Base64 variant, and the mistakes that break links and tokens.

Worked example

Base64. Take the text Hello, World! — 13 characters, 13 bytes in UTF-8. Encoding it to Base64 gives:

SGVsbG8sIFdvcmxkIQ==

The two = signs at the end are padding: 13 bytes do not divide evenly into 3-byte groups, so the encoder pads the final group. Decoding SGVsbG8sIFdvcmxkIQ== returns exactly Hello, World!. You can check the round trip on this page: click Load worked examples, then Encode to Base64, and you should see SGVsbG8sIFdvcmxkIQ==.

URL encoding. Take the value a b&c=d — five characters that would wreck a query string if left raw, because the space is illegal, the ampersand would split the value into two parameters, and the equals sign would look like a new key-value separator. URL-encoding it gives:

a%20b%26c%3Dd

Each unsafe character is replaced by its percent code: the space by %20, the ampersand by %26, and the equals sign by %3D. The letters a, b, c, and d are safe and stay as they are. Decoding a%20b%26c%3Dd returns the original a b&c=d. In a real URL this value would appear as, for example, https://example.com/search?q=a%20b%26c%3Dd, where the server decodes the query value back to a b&c=d.

Related: JSON Formatter & Validator · Color Converter & Contrast Checker · Base64 vs. URL encoding