JWT Decoder
Decode a JSON Web Token and read its header, payload and claims in a readable format, with an instant check of whether the token has expired. Decoding is
Paste a JSON Web Token and read its three parts in a readable form: the header with the signing algorithm, the payload with the claims, and the human-readable timestamps for issued-at, not-before and expiry. The tool tells you immediately whether the token has expired and when it will.
This is the everyday debugging step when an API returns 401 and you need to know whether the problem is the signature, the audience or simply an expired token. Everything is decoded in your browser, so production tokens are never sent anywhere.
How to decode a JSON Web Token
Paste the token
Read the header, payload and expiry
Copy the payload JSON if you need it
FAQ
Does this verify the signature?
No - and that matters. Decoding only base64url-decodes the parts, so the content is readable but not proven authentic. Never treat a decoded token as trusted until your server has verified the signature.
How do I know if the token expired?
The exp claim is a Unix timestamp in seconds and the tool compares it with the current time, showing the date and whether the token is still valid.
What are the difference between exp, iat and nbf?
iat is when the token was issued, nbf is the earliest time it may be used, and exp is when it stops being valid. A token is only acceptable between nbf and exp.
Is it safe to paste a real token here?
The decoding happens entirely in your browser, so the token is not transmitted. Treat any token as a credential anyway: do not paste one into a site you do not trust, and rotate it if it may have leaked.
Why does my token show an error?
A JWT has exactly three dot-separated parts. A missing part, a line break in the middle or a token that is actually an opaque session ID will all be reported as not a JWT.
Is my token uploaded?
No, decoding is local.
At a glance
| Input | text |
|---|---|
| Multiple files | No |
| Where it runs | In your browser - files are never uploaded |
| Works offline | Yes — once the page has loaded |
| Price | Free, no sign-up, no watermark |
Handling secrets safely
Developer tools process credentials more often than people realise, and the risk is not the algorithm but where the data goes. Hashing is one-way and is not encryption - MD5 and SHA-1 are broken for anything security-related, and even SHA-256 is the wrong tool for storing passwords, where bcrypt, scrypt or Argon2 exist precisely to be slow. Base64 is an encoding, not protection: anyone can decode it, so never treat it as obfuscation. A JWT can be read by anyone who holds it, which is why the payload must never contain secrets, and decoding a token does not verify its signature - verification requires the key. Everything on this site runs locally in your browser, which is the reason it can safely handle tokens and passwords at all.
Where conversions quietly break
Most conversion bugs are not about syntax, they are about meaning. A CSV column of postcodes loses its leading zeros the moment a spreadsheet guesses it is a number; a long ID exceeds floating-point precision; dates change meaning depending on whether they are day-first or month-first. JSON keys are unordered but arrays are not, and a tool that sorts keys changes nothing while one that sorts arrays changes the data. Unicode is another trap: text can arrive as UTF-8, UTF-16 or with a byte-order mark, and a decoder that guesses wrong turns accented characters into mojibake. Before trusting any conversion, spot-check the first and last row, any field with leading zeros, and any field containing quotes, commas or newlines.