Guide
Base64 vs Base64URL
Learn when to use + and / or - and _, how padding works, and why compact JWT segments use Base64URL.
by Tools in a Tab · Published on · Reviewed on
Short answer
Base64 and Base64URL represent the same bytes in six-bit groups, but they use slightly different alphabets to fit different channels.
| Value | Standard Base64 | Base64URL |
|---|---|---|
| Index 62 | + |
- |
| Index 63 | / |
_ |
| Padding | Canonical = |
May be omitted when the protocol defines it |
+ and / have special roles in some URL contexts. The URL-safe variant
replaces them; it is neither encryption nor compression.
Do not replace two characters blindly
Correct conversion also handles padding and validates length. The receiver
must know how many bytes the final group represented. Some protocols omit =
because it can be reconstructed; others require padded standard Base64.
RFC 4648 defines the Base64URL alphabet. Follow the profile of the protocol in use rather than a general assumption about every URL.
JWT uses Base64URL
Compact JWT segments are Base64URL values separated by dots. The JWT decoder understands that variant and warns that reading the content does not verify its signature.
The Base64 converter lets you select standard Base64 or Base64URL explicitly and decide whether URL-safe output keeps padding. The selection prevents silent interpretation under the wrong rules.
Quick choice
- MIME or a field that requires RFC 4648 Base64: standard alphabet.
- JWT, JWS, or another protocol specifying Base64URL: URL-safe variant.
- Your own application parameter: define alphabet, padding, and byte handling in the contract.
Do not assume arbitrary decoded bytes are text. Base64 can represent any byte sequence, but the result is text only if those bytes form a valid character encoding such as UTF-8.