Paste a Base64 string, for example a payload or state parameter copied from a URL. The decoder accepts both the standard and the URL-safe alphabet, with or without = padding and even when the URL percent-encoded it. Text and JSON are shown as text, anything else as hex, and a JWT is split into its header and payload. Everything runs in your browser.
Standard vs URL-safe Base64
RFC 4648 defines two alphabets that differ in two characters. The standard one uses + and /, which have a meaning in URLs; the "URL and filename safe" one (section 5) uses - and _ instead. JWTs use the URL-safe alphabet without padding (RFC 7515).
| Standard (RFC 4648 §4) | URL-safe (RFC 4648 §5) | |
|---|---|---|
| Characters 62 and 63 | + and / | - and _ |
| Padding | = to a multiple of 4 | Often left out |
| Safe in a query value as-is | No: + becomes a space, / and = need care | Yes |
Base64 copied from a URL
A standard Base64 value inside a query string often arrives damaged in one of two ways. Either it was percent-encoded (%2B, %2F, %3D), or a + was decoded as a space by form-decoding rules. The decoder undoes both: it percent-decodes first and reads spaces as +. Line breaks, as in wrapped MIME output, are ignored.
Decoding a JWT
A JSON Web Token is three URL-safe Base64 parts joined by dots. The tool decodes the first two, the header and the payload, so you can read the claims. It does not check the signature, so a decoded token says nothing about whether it is genuine. Do not paste production tokens into tools you do not trust; this one does not send them anywhere. See JWTs in URLs for why tokens in URLs are risky.