Encode text with the URL-safe Base64 alphabet from RFC 4648 section 5: minus and underscore replace plus and slash, and padding is normally dropped, so the result is safe in URLs, filenames and JWTs.
Show calculation steps
Processed privately in your browser — nothing you paste is uploaded, logged or stored.
How to use the Base64URL Encoder
- Paste the text you want to encode – often a JSON object destined for a token or a value for a URL.
- Leave the padding option off, which matches how Base64URL is used in JWTs and most web APIs.
- Click "Encode to Base64URL".
- Copy the result; it is safe to place directly in a URL path, query string or filename.
Frequently asked questions
How does Base64URL differ from ordinary Base64?
Only in two characters and the padding. RFC 4648 section 5 replaces plus with minus and slash with underscore, because plus and slash carry special meaning inside URLs. Padding with "=" is normally omitted as well, since it is reserved in query strings.
Can I paste Base64URL where a normal Base64 decoder is expected?
Usually not without conversion. A strict standard decoder rejects minus and underscore. The safe move is to translate minus back to plus and underscore back to slash, restore the padding, and only then decode – or simply use the Base64URL Decoder here.
Why is padding dropped so often?
Because the length is recoverable without it and "=" needs escaping in URLs. Decoders reconstruct the missing characters from the input length, which is why unpadded tokens decode correctly.
Is this the encoding used inside JSON Web Tokens?
Yes. A JWT is three Base64URL sections joined by dots: header, payload and signature. Encoding a JSON header or payload here produces exactly what those sections contain.
