Base64 / URL / JWT Encoder & Decoder

Encode and decode Base64 or URLs and inspect JWT headers and payloads in the browser.

Text or JWT

Output

How to use

Paste or type your input in the "Text or JWT" box: plain text to encode, a Base64 or percent-encoded string to decode, or a JWT to inspect.
Click "Base64 encode" or "Base64 decode" to convert between text and Base64, or "URL encode" or "URL decode" to add or remove percent-encoding. The result, or an error message, appears in the "Output" box.
To inspect a token, paste it with or without the Bearer prefix and click "Decode JWT". The header and payload appear as indented JSON, and any iat, nbf and exp claims in the payload are listed under "JWT time claims", with numeric values converted to UTC and your local time.
Click "Copy result" to copy the output. To reverse an encoding, paste the encoded text into the "Text or JWT" box and click the matching decode button. Decoding and then encoding again may not give back the exact original: URL-safe or unpadded Base64 comes back in the standard alphabet with = padding where needed, and "URL encode" turns a + left by "URL decode" into %2B.

Frequently asked questions

Is the text or token I paste sent anywhere?

No. Encoding and decoding run in your browser with JavaScript, and what you enter is not sent to LeedyBox. A JWT is often used as a login credential and can work for anyone who has it until it expires or is revoked, so treat a live token like a password and do not share it in screenshots or chats.

Why does "Base64 decode" say the data is not valid UTF-8 text?

"Base64 decode" shows the decoded bytes as UTF-8 text and stops with this error when they are not valid UTF-8, for example for PNG or JPEG images, most PDFs and compressed data, and often for text saved in another encoding such as Latin-1 or Shift_JIS. The tool does not save decoded bytes as a file, so use it for Base64 that contains text. A data URI such as data:image/png;base64,... is rejected as invalid Base64, because the colon, semicolon and comma are not Base64 characters.

Does it handle URL-safe Base64 and missing padding?

Yes, when decoding: "Base64 decode" accepts the standard alphabet (+ and /) and the URL-safe alphabet (- and _), with or without = padding, and ignores spaces and line breaks. "Base64 encode" outputs the standard alphabet with padding; for the URL-safe form used in JWTs, replace + with -, / with _ and remove the trailing = signs. Text is encoded as UTF-8 exactly as entered, so a trailing space or line break changes the result, and line breaks in the box are encoded as LF.

Should I paste a whole URL into "URL encode"?

Usually not. "URL encode" works like JavaScript's encodeURIComponent: it percent-encodes every character except A–Z, a–z, 0–9 and - _ . ! ~ * ' ( ), so the / ? & = : and # that structure a URL are encoded as well. Use it for a single part, such as one query parameter value. Spaces become %20, and non-ASCII characters are encoded as their UTF-8 bytes, so é becomes %C3%A9.

Why are plus signs not turned into spaces, and when does "URL decode" report an error?

"URL decode" works like JavaScript's decodeURIComponent: it decodes %XX escape sequences and leaves + unchanged, because in the general URL syntax (RFC 3986) + does not stand for a space. HTML form data (application/x-www-form-urlencoded), which many query strings use, encodes spaces as +, so replace each + with a space before decoding such data; a real plus sign in that format is written as %2B and is still decoded correctly. The error appears when a % is not followed by two hexadecimal digits, as in 50% off, or when the escaped bytes are not valid UTF-8, as in %E2%82.

Which tokens can "Decode JWT" read?

Tokens in the three-part compact form header.payload.signature used by signed JWTs (JWS), including unsigned tokens with an empty signature part. The signature part is not checked, so a decoded token is not proof that it is genuine. Encrypted tokens (JWE) have five parts and their payload cannot be read without the key, so they get a format error. A header or payload that does not decode from Base64 to JSON, or a payload that is a plain value such as a string or number instead of a JSON object, gives a "JWT parse error" message. Integers larger than 9,007,199,254,740,991 in the header or payload can be rounded when the browser parses the JSON, so long numeric IDs may be shown with different last digits.

How are the exp, nbf and iat times shown, and when is a token marked expired?

The values are read as Unix time in seconds, as the JWT standard (RFC 7519) defines them, and shown in UTC and your local time. "EXPIRED" and "Not valid yet" compare exp and nbf with your device's clock at the moment you click "Decode JWT", with no allowance for clock differences, so a wrong clock gives a wrong status. Servers may allow a small leeway, often no more than a few minutes, so near the exp or nbf time a server can decide differently from the status shown here. A time written as a string, such as "1700000000", is reported as not a valid numeric Unix timestamp.