Base64URL Encoder & Decoder
The URL-safe Base64 variant defined in RFC 4648 §5: + becomes -, / becomes _, and trailing = padding is removed. The result can be dropped into a URL path, a query parameter or an HTTP header without further escaping.
This is the encoding used by JSON Web Tokens, so each of the three dot-separated segments of a JWT is a Base64URL value.
How to use it
- Paste text on the left to produce a URL-safe encoding.
- Press Swap to decode a Base64URL value back to text.
- Padding is restored automatically when decoding, so values copied from a JWT or a URL work directly.
Padding, and why decoding still works without it
Base64 encodes three bytes at a time; when the input length is not a multiple of three, standard Base64 appends one or two = characters so the output length is a multiple of four. Because the required amount of padding can be computed from the length alone, the URL-safe variant simply omits it and decoders add it back.
This converter does exactly that, which is why a JWT segment pasted straight out of an Authorization header decodes without you editing anything.
Frequently asked questions
When should I use this instead of standard Base64?
- Whenever the value will appear in a URL, a filename or an HTTP header. In a URL, a + from standard Base64 is interpreted as a space and a / changes the path, both of which corrupt the value.
Can I decode a whole JWT here?
- You can decode any single segment, but the dedicated JWT decoder splits the token for you and interprets its expiry and issued-at claims as readable dates.
Is the missing padding a problem?
- No. It is reconstructed from the string length before decoding, so both padded and unpadded input work.