Base64URL Encoder

Ordinary Base64 has two problems when it travels in web addresses and similar places. Its alphabet includes + and /, which URLs treat as a space and a path separator, and it ends with one or two = signs, which separate names from values in query strings. Base64URL is the small variant that fixes both, and it is the encoding inside JSON Web Tokens, many signed cookies and a good deal of modern API plumbing.

What changes

The alphabet is the same sixty-four characters apart from two: the character for value 62 is - instead of +, and the one for value 63 is _ instead of /. The grouping is identical, three bytes into four characters, and the output is the same length. Padding is optional in the standard and is usually dropped, because the length of the encoded text already tells a decoder how many bytes the last group holds.

Why padding can go

Without padding, an encoded string has a length that leaves 0, 2 or 3 characters in the last group, which stand for 3, 1 or 2 bytes. A length that leaves 1 is impossible. A decoder can restore the missing = signs from the length, which is what the one on this page does. The “Keep = padding” switch writes them on output for systems that insist.

Using the page

Choose encode or decode, and say whether the input is text (UTF-8) or hexadecimal bytes. The decoder accepts either alphabet, so a string copied from a standard Base64 source decodes too, and re-encoding it gives the URL-safe form. That makes the page a quick way to convert between the two. The output shows the byte and character counts, and a character outside both alphabets is reported with its position.

In JSON Web Tokens

A JWT has three parts separated by dots: a header, a payload and a signature, each in Base64URL. The first two are JSON documents, so decoding them as text shows the algorithm, the claims and the expiry. The page decodes them, but it does not check that the signature is valid, and it should not be used to decide whether a token can be trusted. The JWT decoder tool presents all three parts together and describes standard claims.

A worked example

The Sample button loads the text subjects?_d=1&filter=a/b+c, which is 26 bytes. Ordinary Base64 of it would include characters that need escaping in a URL. The Base64URL encoding is c3ViamVjdHM_X2Q9MSZmaWx0ZXI9YS9iK2M, 35 characters with no padding needed. The underscore in it stands for the value 63, the one that standard Base64 writes as a slash. A shorter test is the text ???>>>, whose standard encoding is Pz8/Pj4+ and whose Base64URL form is Pz8_Pj4-.

Limits

Base64URL is an encoding. It does not hide, compress or protect the data, and anyone can decode a token’s payload. The page treats whatever you paste as a single block; it does not split tokens, check signatures, or validate that the decoded text is JSON. If the decoded bytes are not valid UTF-8 text, switch to hexadecimal output. Very large inputs are fine but are slower to render.

Related tools

• Base64 Encoder handles files and the standard alphabet.
• JWT Decoder splits a token and explains its claims.
• URL Encoder escapes characters with percent signs instead.
• Base32 Encoder is a case-insensitive alternative.