How does URL-safe Base64 differ from standard Base64?

The encoded data is identical except for two characters. Standard Base64 uses + and /, both of which have special meaning in URLs and file paths. URL-safe Base64 (RFC 4648 §5, also called base64url) substitutes - for + and _ for /, so the string needs no percent-encoding.

Why is padding often removed?

The trailing = characters are only there to make the length a multiple of four. In URLs an = can be ambiguous or need escaping, so base64url commonly drops it. The length still implies how many bytes the final group holds, so a correct decoder recovers the data without padding.

Is this the encoding used by JWTs?

Yes. JSON Web Tokens encode their header, payload and signature with base64url and no padding, joined by dots. You can paste a single JWT segment here to decode it, or encode a JSON payload into the base64url form a JWT expects.

Will it decode standard Base64 too?

Yes. The decoder normalizes - back to + and _ back to /, strips whitespace, and tolerates missing or present padding, so it accepts both the standard and URL-safe alphabets without you choosing which one you have.

Does my data leave the browser?

No. Encoding and decoding, including UTF-8 handling, run entirely in your browser. Nothing is uploaded.

URL-Safe Base64 Encoder/Decoder

URL-safe Base64 is the variant of Base64 you reach for when the encoded value has to live inside a URL, query string, file name or token without breaking anything. This tool encodes UTF-8 text to URL-safe Base64 and decodes it back, following RFC 4648 §5, all in your browser.

How it works

The underlying transform is ordinary Base64: input bytes are taken three at a time (24 bits) and split into four 6-bit values, each mapped to a character. The only change for the URL-safe alphabet is the last two symbols. Standard Base64 ends its alphabet with + and /; URL-safe Base64 uses - and _ instead, because + is read as a space and / is a path separator in URLs. The result therefore survives in a link without percent-encoding.

Padding is optional. Standard Base64 pads the final group with = to a multiple of four characters, but base64url normally drops it since the length already implies how many real bytes the last group contains. This tool lets you keep or drop the padding when encoding, and its decoder accepts input with or without it, in either alphabet, after stripping whitespace.

Tips and notes

This is the exact encoding inside JSON Web Tokens: a JWT is three base64url segments joined by dots, with no padding. Paste one segment to inspect a header or payload, or encode JSON here to build one. If a downstream system rejects your value, check whether it expects padding, and remember that the encoded bytes are not encryption, only a reversible encoding, so never put secrets in a base64url string and assume they are hidden.