Base64URL Encoder / Decoder
Encode and decode URL-safe Base64.
// Why URLs need their own Base64
A + inside a query string is read as a space by many form parsers, a / inside a path segment looks like a directory separator, and = is reserved for separating a parameter name from its value. Pasting a standard Base64 value into a URL therefore means escaping it first, and escaping it again every time it is moved.
Base64URL removes the problem at the source: - takes the place of +, _ takes the place of /, and the trailing = padding is dropped. What is left is A-Z, a-z, 0-9, - and _, all of which are unreserved in a URL, so the same string can go into a query string, a path segment, a filename or a token without being rewritten.
// Where a URL-safe value shows up
JSON Web Tokens
The header, payload and signature of a JWT are Base64URL without padding. Decoding a segment here shows the JSON that the token carries.
Cursors and signed links
Pagination cursors and signed file links are usually opaque URL-safe strings. Decoding one is the quickest way to see the parameters it hides.
Filenames and object keys
A filename cannot contain /, and + and = are awkward everywhere. The Base64URL alphabet avoids all three, so one value works as a name and as a URL.
// Base64URL beside standard Base64
- >Alphabet — Standard writes + and /; Base64URL writes - and _ instead. The other 62 characters are identical, which is why converting is a straight swap.
- >Padding — Standard pads to a multiple of four characters with =. Base64URL may skip it, and this page does, so an encoded value is up to two characters shorter.
- >Where each one travels — Standard Base64 suits JSON fields, email bodies and MIME attachments. Base64URL suits query strings, path segments, JWT parts, cursors and filenames.
// One value, standard and URL-safe
IN
😀
OUT
8J-YgA
The standard encoding of the same emoji is 8J+YgA==; Base64URL writes - for + and drops the padding, so the value needs no escaping.
// Questions about Base64URL
Is Base64URL different from Base64?
The encoding is the same; only three characters change. - replaces +, _ replaces /, and the trailing = padding is usually left out. Converting between the two is those swaps and nothing else.
Does the decoder accept standard Base64 too?
Yes. Values using + and / are accepted as well, and missing padding is added before decoding, so pasting a standard string works the same way.
Why is there no = padding in the output?
RFC 4648 allows base64url to skip padding, and token formats such as JWT do skip it. Leaving it out keeps the value shorter and avoids a character that some query-string parsers treat specially.