Standard Base64 vs URL-safe Base64
+/ vs -_ alphabets, padding, and when URL-safe is required in query strings and JWT segments.
Standard Base64 uses + and /. Those characters mean something else in a query string, so a naive copy into a URL breaks. URL-safe Base64 swaps them for - and _, often dropping = padding.
JWT header and payload are Base64URL without padding. Email attachments and many data URLs still use the classic alphabet with padding. Decoding the wrong variant looks like garbage or throws.
The studio can switch alphabet. If a string came from a JWT, stay on URL-safe. If it came from an MIME body, stay on standard. Encoding is not encryption in either case.
Standard Base64 uses + and / and may include = padding and line breaks. URL-safe Base64 uses - and _ so the string survives a query or a filename. They are not interchangeable until you map the two alphabets and restore padding. A JWT uses the URL-safe alphabet. This page is the difference. The converter has a switch for the alphabet.
| Trait | Standard | URL-safe |
|---|---|---|
| Alphabet | + and / | - and _ |
| Padding | Often ends with = | JWT segments usually omit it |
| Use | MIME, many data URLs | Query strings, JWT header/payload |
FAQ
Can I mix them?
Not in one string. Convert or re-encode with the alphabet the consumer expects.
Padding?
Standard often ends with =. URL-safe JWT segments usually omit padding.