Boneyard Tools

Base64 vs base64url: padding and URL-safe encoding

How standard Base64 and the URL-safe base64url variant differ, why padding exists, and when each one is the right choice for your data.

One binary format, two alphabets

Base64 exists to carry raw bytes through channels that only accept text, such as email bodies, JSON fields, and data URIs. It slices the input into 6-bit chunks and maps each chunk to one of 64 printable characters. The first 62 symbols are always A to Z, a to z, and 0 to 9. Only the final two positions differ between variants, which is why the same bytes can look slightly different depending on the encoder that produced them.

Why '+' and '/' break inside URLs

Standard Base64 uses '+' and '/' for its last two symbols, and both carry special meaning on the web. A '+' can be read as a space in query strings, and '/' is the path separator, so a raw Base64 token dropped into a URL or filename is easily corrupted. The base64url variant, defined in RFC 4648, replaces '+' with '-' and '/' with '_'. Those two characters are safe in paths, query parameters, and filenames, which is why JWTs and many API tokens use base64url.

The role of the '=' padding

Because Base64 works in blocks of four characters that represent three bytes, an input whose length is not a multiple of three leaves one or two characters short. Encoders fill the gap with '=' so the output length is always a multiple of four. A string ending in one '=' means the last block held two bytes, and two '=' means it held one byte. base64url usually omits this padding to keep tokens compact, which is why decoders must be able to re-add it before working.

How this decoder bridges both

Rather than force you to know which variant you have, the tool normalizes everything first. It strips whitespace, rewrites '-' and '_' back to '+' and '/', and appends the missing '=' characters to reach a length divisible by four. Only then does it decode the bytes and read them as UTF-8. A remainder of exactly one character after cleanup is impossible for valid Base64, so that specific case is reported as an error instead of producing nonsense.

Frequently asked questions

Can I paste a JWT and read it here?

A JWT is three base64url parts joined by dots. Paste a single part, such as the header or payload, without the dots and it decodes to readable JSON. Pasting the whole token including the dots will fail because the dots are not part of the Base64 alphabet.

Do I need to add the '=' padding myself?

No. The decoder re-pads the string automatically to the next multiple of four, so base64url values that ship without padding decode without any manual editing.