Base64url Encode

What the Base64url Encode tool does

This turns your text into Base64url, the URL-safe version of Base64. Type or paste your text, press Convert, and copy or download the result. It produces the same kind of encoding you would get from ordinary Base64, but using characters that are safe to drop straight into a web address, a filename, or a cookie without anything breaking.

It runs in your browser, so nothing you enter is uploaded.

How to use it

1. Enter your text. Type or paste it, or upload a plain text file.
2. Press Convert. The Base64url output appears, ready to Copy or Download.

Why standard Base64 is not URL-safe

Regular Base64 is brilliant for carrying data as text, but it was not made with web addresses in mind, and three of its characters cause trouble there. It uses the plus sign and the forward slash as part of its alphabet, and the equals sign for padding at the end. Inside a URL, all three mean something else: a plus sign can be read as a space, a slash separates the parts of a path, and an equals sign has its own role in query strings. So if you paste ordinary Base64 into a link, it can be misread or mangled, and you would have to encode it a second time to make it safe. That double handling is exactly the headache Base64url removes.

What Base64url changes

Base64url is not a different encoding so much as the same one with its two awkward characters swapped out. Wherever standard Base64 would use a plus sign, Base64url uses a hyphen, and wherever it would use a slash, Base64url uses an underscore. The padding equals signs at the end are simply left off. That is the whole difference. The hyphen and underscore are both perfectly safe inside a URL or a filename, so the result drops in with no further escaping needed. The underlying work, the way three bytes become four characters, is identical to regular Base64, which the Base64 Encode tool explains in full. This is just that output, dressed for the web.

Where it is used: JWTs and URLs

The place you meet Base64url most is the JWT, or JSON Web Token, the compact tokens that carry login and identity information around modern web apps. Every part of a JWT is Base64url-encoded, and that is precisely why a token can sit in a web address or an HTTP header without falling apart. Beyond that, Base64url is the natural choice any time you need to tuck encoded data into a place the standard version would break: a value in a query string, a part of a path, a filename, or a cookie. If your encoded data is going anywhere near a URL, this is the form to use.

Going the other way

If you have Base64url and want the original text back, that is the opposite job, handled by the Base64url Decode tool. And if you need the ordinary, non-URL-safe form of Base64, the Base64 Encode tool produces that, and is also where the underlying encoding is explained in detail.

Questions people ask

How is Base64url different from regular Base64?

It swaps the two characters that cause problems in web addresses: a hyphen replaces the plus sign and an underscore replaces the slash, and the padding is dropped. The encoding is otherwise the same.

Why is there no equals sign at the end?

Because the padding equals signs that standard Base64 adds are left off in the URL-safe form, since they have a special meaning in URLs. The decoder works them out again when needed.

Is this what JWTs use?

Yes. The parts of a JSON Web Token are Base64url-encoded, which is what lets a token travel safely inside a URL or an HTTP header.

Can I put the result straight into a URL?

That is the whole point of it. The hyphen and underscore it uses are safe in a web address, so the output drops in without any extra encoding.

References

1. Josefsson, S. (2006). RFC 4648: The Base16, Base32, and Base64 Data Encodings (Section 5 defines the URL and filename safe alphabet). Internet Engineering Task Force (IETF). https://www.rfc-editor.org/rfc/rfc4648
2. Jones, M., Bradley, J., Sakimura, N. (2015). RFC 7519: JSON Web Token (JWT). Internet Engineering Task Force (IETF). https://www.rfc-editor.org/rfc/rfc7519