Base64 vs URL-safe Base64 (and when JWT needs the latter)
Standard Base64 uses +/= ; URL-safe swaps in -/_ and often drops padding. How QSTools encodes UTF-8 text in the browser.
Base64 turns bytes into ASCII so they survive email, JSON, and copy-paste. It is encoding, not encryption: anyone can decode it. UTF-8 text must be encoded to bytes first, or non-ASCII characters will break naive btoa usage.
Standard vs URL-safe
| Flavor | Alphabet / padding | Typical use |
|---|---|---|
| Standard (RFC 4648 §4) | A–Z a–z 0–9 + / with = padding |
MIME, many APIs, config blobs |
| URL-safe (RFC 4648 §5) | - _ instead of + /; padding often omitted |
Query strings, filenames, JWT segments |
JWT header and payload are Base64URL (URL-safe) without relying on + / / in paths. If you paste a JWT into a “standard only” decoder, you can get false failures.
What QSTools does
Our Base64 Encode / Decode tool runs entirely in the browser, supports UTF-8, and toggles URL-safe mode. Use Encode for plain text → Base64; Decode for the reverse. Swap is handy when you want to round-trip a sample.
Common decode failures
- Truncated paste or stray whitespace (we strip spaces/newlines on decode)
- Mixing URL-safe input with standard mode (or the opposite)
- Binary that is not valid UTF-8 when you expect readable text
For inspecting tokens end-to-end, pair this with the JWT Decoder — still client-side.