About Base64URL Encode
Base64URL is the variant of Base64 designed for places where a string has to survive being part of a URL, a filename or a JSON Web Token. It makes two changes to the standard alphabet: + becomes -, and / becomes _. Both of those characters have reserved meanings in URLs and file paths, which is exactly why they cannot appear in an identifier you intend to paste into either.
The third difference is padding. Standard Base64 pads its output with = to a multiple of four characters; this variant omits that padding entirely. JWTs are the most familiar example — look at any token and you will see three dot-separated segments containing no = at all.
A useful consequence is that Base64URL output needs no percent-encoding before it goes into a query string. That keeps generated URLs shorter and removes an entire class of bug where an encoded value gets double-encoded during transmission.
How to use Base64URL Encode
- 1 Paste the text you want to encode as a URL-safe token.
- 2 The result is produced instantly — + and / are replaced by - and _, and padding is removed.
- 3 Copy the output straight into your URL, filename or JWT payload.
Frequently asked questions
How is this different from normal Base64?
Two characters differ and the padding is dropped. Standard Base64 uses + and / and pads with =; Base64URL uses - and _ and leaves the padding off. Decoders for one will often reject the other, so it matters which you use.
Do I need to URL-encode the result?
No. That is the point of the URL-safe alphabet — every character in the output is already permitted inside a URL, so it can be placed directly into a query parameter or path segment without percent-encoding.
Why is there no padding on the output?
Because = is not permitted in some of the contexts Base64URL is used in, and because the length of the original data can be recovered from the unpadded length. Omitting it keeps tokens compact and avoids a character that would otherwise need escaping.
Is it safe to put an encoded password in a URL this way?
Encoding is not protection. Anyone who sees the URL can decode the value instantly. Use it to keep secrets out of URLs altogether — for example, put credentials in a POST body or a header rather than a query parameter.
Free, online, and private
Free to use
Base64URL Encode is completely free. There is no account to create, no login, and no hidden charge or usage limit.
Runs online in your browser
It is a free online tool that runs entirely in your browser. Nothing to download or install — open the page and start using it right away.
Your data stays private
All processing happens locally on your device. Your input is never uploaded, stored, or tracked, so it never leaves your browser.
How Base64URL Encode behaves in detail
These are the specifics of this implementation — the exact ranges, defaults and fixed settings you are working with.
| Parameter | Value |
|---|---|
| Pipeline | standard Base64 first, then + rewritten to - and / rewritten to _ |
| Padding | the trailing = characters are removed, so the result is unpadded |
| Character set produced | A-Z, a-z, 0-9, hyphen and underscore only |
| Input encoding | UTF-8, so multibyte characters are encoded as their UTF-8 bytes |
| Line breaking | none — the output is a single line whatever its length |
Compiled from the implementation of this tool and checked against it by itoolnet.
What Base64URL Encode does not do
Knowing the edges of a tool saves more time than another list of its features. These are the cases where it will not do what you might expect.
- The trailing = characters are stripped and there is no switch to keep them. Specifications and libraries that expect padded input cannot consume this output directly, and re-adding the padding is left to whoever reads it.
- Only UTF-8 text can be supplied. Raw bytes — a file's contents, a binary key, anything that is not valid UTF-8 — cannot be entered here, because the field is text and everything in it is passed through TextEncoder first.
- This tool converts in one direction only. Recovering readable text from a URL-safe string is a separate operation, and it tolerates both padded and unpadded input, so the missing = is not itself a problem for that path.
Tested and documented by itoolnet, the team that builds and maintains this site.