Decode a JWT's header and payload, or encode and decode Base64, URL and HTML entities in your browser. ROT13, Caesar shifts and SHA-1 or SHA-256 are included too.
If this tool isn’t working as expected, please take a screenshot of the error and report the problem here so we can investigate and improve it.
A JWT decoder first: it reads a token's header and payload and shows them as formatted JSON, with exp, nbf and iat converted to UTC dates. The same page is a Base64 encoder and decoder (standard or URL-safe Base64URL, with or without padding), a URL encoder and decoder for percent-encoding, and an HTML entity encoder.
ROT13, Caesar shifts and SHA-1 or SHA-256 hashing are there as extras. All of it runs in your browser, so tokens and headers you paste are not sent to a server.
A JWT is three Base64URL segments separated by dots: header, payload and signature. The first two are plain JSON that anyone holding the token can read. This page decodes them but does not check the signature, which needs the issuer's key, so a decoded exp date tells you what the token claims, not whether a server will still accept it.
Paste the text, encoded string or JWT you want to convert.
Pick Base64, URL, HTML, JWT Decode, a cipher or a hash. Pasting a JWT switches to JWT Decode if you haven't picked a mode yet.
Press Process. If the input doesn't fit the operation, the message says what is wrong.
Copy the result, or download it as a text file.
Paste the JWT from an Authorization header or a cookie (a leading "Bearer " is ignored). Read sub, aud and scope, and see whether exp has passed.
Base64 Decode on the part after "Basic " shows the user:password pair. Base64 Encode builds one for a test request.
URL Decode turns %20, %26 and %2F sequences in a logged or analytics URL back into readable text.
HTML Encode turns &, <, >, double quotes and single quotes into entities, so a snippet displays as text instead of being parsed as markup.
If a Base64 Decode result is JSON, paste it into the JSON Formatter to read it with indentation.
JWT
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cJWT Decode result
{
"header": {
"alg": "HS256",
"typ": "JWT"
},
"payload": {
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}
}
iat - issued at: 2018-01-18 01:30:22 UTCThe header and payload are printed together, and numeric exp, nbf and iat claims are also written out as UTC dates. The third segment, the signature, is not verified or shown.
Base64 Decode input
eyJuYW1lIjoiSm9zw6kifQText
{"name":"José"}Base64 Decode accepts the URL-safe alphabet used in JWTs, with or without padding, and reads the bytes as UTF-8, so the é survives.
Text
hello world & moreURL Encode result
hello%20world%20%26%20moreThis is component encoding, so every character that isn't safe inside a single query parameter is escaped, including the &. Encoding a whole URL this way would also escape its slashes and colons.
Text
<div class="test">HTML Encode result
<div class="test">The five characters with special meaning in HTML - &, <, >, double quote and single quote - are replaced; the single quote becomes the numeric entity '.
Signatures aren't checked, and the expired / not-yet-expired labels compare exp with your device's clock, so a wrong system clock changes them.
For Base64URL output, encode here and then replace + with -, / with _ and remove the trailing = characters yourself.
The input is one text box, so there's no file upload. Images have their own page, Image to Base64.
MD5, SHA-384, SHA-512 and file hashing are on the Hash Generator page.
Short answers on what Base64 and a JWT do and don't protect, what Base64URL is, and why a string refuses to decode.
Yes, for the header and payload: they're only Base64URL-encoded JSON, so anyone can read them. What you can't do without the issuer's secret or public key is confirm the signature, so this page shows what a token claims but can't tell you whether it is genuine or untampered.
Base64URL swaps + and / for - and _ and usually drops the trailing = padding, so the text can sit in a URL without escaping. A JWT uses it for all three of its segments.
No. Base64 is a reversible encoding: anyone can turn it back into the original text with no key. It exists to carry binary data or special characters through text-only places such as URLs, JSON and email headers. ROT13 and the Caesar cipher are just as easy to reverse. If data has to stay confidential, encrypt it - encoding alone protects nothing.
Standard and URL-safe Base64 both work here, with or without = padding, and spaces and line breaks are ignored, so the usual causes are different: a data:...;base64, prefix in front of the string (remove it, or use Image to Base64 if it's an image), quotes or other characters copied along with it, a string cut short while copying, or data that isn't text. Bytes that aren't valid UTF-8 text, such as an image or a ZIP file, are reported as an error.
URL encoding (percent-encoding) makes text safe inside a URL: a space becomes %20 and & becomes %26. HTML encoding makes text safe inside markup: < becomes < and & becomes &, so the browser shows the characters instead of parsing them. Each protects a different destination, so encoding a URL parameter with HTML entities doesn't make it a valid URL, and the reverse fails too.
Every operation runs in your browser with JavaScript and the Web Crypto API, and nothing is sent to a server. Still, a live JWT is a credential: anyone who has it can use it until it expires. Prefer tokens from a test environment when you can.
Leave your email so we can prioritize similar tools and updates.