Base64URL · URL-safe Base64
Paste either flavour and it decodes: standard Base64 or URL-safe, with or without padding. URL-safe swaps + and / for - and _ and drops the trailing =, which is exactly the form JWT segments use.
Processed as you paste — no button to press (Ctrl+Enter converts now / Esc clears)
Drop a file here, or — Ctrl+V a screenshot works too
Any file type · 100 MB maximum
Paste, drag and drop, or Ctrl+V a screenshot
Three characters differ from standard Base64
| Standard | URL-safe | Why |
|---|---|---|
+ | - | A plus in a query string decodes to a space |
/ | _ | A slash would look like a path separator |
= | omitted | Padding is redundant when the length is known |
When you must use it
- JWT — all three segments are Base64URL per RFC 7515
- URL parameters and filenames — anywhere the string travels through a URL
- Cookies and tokens — where a literal
+or/would be re-interpreted
Decoding needs no manual edits
You do not have to convert - back to + or re-add padding first. The decoder recognises the URL-safe alphabet, normalises it and fills in the missing padding, then tells you which normalisation steps it took.
Frequently asked questions
Can I decode a JWT segment directly?
Yes — a single segment, or the whole token. Pasting the full token gives you the header and payload laid out as readable JSON; see JWT decoding.
How do I output URL-safe Base64 when encoding?
Turn on the URL-safe option in text mode. The output uses - and _ and omits padding, exactly as RFC 4648 §5 specifies.
Why does some Base64 end without the = signs?
Because it is the URL-safe variant, which drops padding by convention. The missing characters do not change the data — padding is derivable from the length.
Can the two alphabets be mixed?
They should not be. A string containing both + and - is malformed, and strict decoders reject it. This tool is lenient and normalises what it can, but producers should pick one alphabet and stay with it.