JWT Decoder
Decode a JSON Web Token to read its header and claims. Nothing is sent anywhere.
Runs entirely in your browserRelated Tools
A JWT Is Not Encrypted
This is the single most important thing to understand about JSON Web Tokens, and it catches people constantly. The header and payload are base64url-encoded, not encrypted. Anyone holding the token can read every claim inside it, without any key at all — which is exactly what this page is doing.
The signature does not hide the contents. It proves they have not been altered. Those are completely different guarantees, and confusing them leads to real breaches: never put a password, a private key, a full credit card number, or anything else confidential into a JWT payload.
The Three Parts
- Header — the signing algorithm (
alg) and token type. Sometimes a key identifier (kid) telling the verifier which public key to use. - Payload — the claims. Standard ones include
sub(subject),iss(issuer),aud(audience),exp(expiry),iat(issued at), andnbf(not valid before). Applications add their own alongside these. - Signature — computed over the first two parts with a secret or private key. It is what makes the token tamper-evident.
Time claims are stored as Unix timestamps in seconds, which is why this tool renders them as readable dates — a raw 1735689600 tells you very little at a glance.
The alg: none Attack
Early JWT libraries had a notorious flaw. The header declares which algorithm to verify with, and some implementations trusted it — so an attacker could set alg to none, strip the signature, and have the token accepted as valid.
A related variant swaps RS256 for HS256, tricking a server into verifying with its own public key as if it were a shared secret. Both are fixed in maintained libraries, but the lesson stands: the verifier must decide which algorithm is acceptable, not the token.
Why This Tool Does Not Verify
Verifying a signature requires the signing secret or the issuer’s public key. Pasting a production signing secret into any web page — including this one — is a bad idea regardless of what the page promises, because you cannot audit what it does with it.
Verification belongs in your own code or on the command line, where the key never leaves your control. Decoding, on the other hand, is completely safe: it uses no key and reveals only what the token already exposes to anyone holding it.
Debugging a Token That Is Being Rejected
When an API returns 401 with a token that looks fine, the cause is usually visible in the payload before you reach for logs.
Check exp first. Expiry is the most common answer by a wide margin, and this page renders it as a readable date precisely so you do not have to convert a Unix timestamp in your head.
Then nbf. A not-before claim in the future rejects the token just as firmly as expiry, and it catches people out when server clocks drift apart.
Then aud and iss. A token minted for one audience and presented to another is rejected by any correct verifier. In a system with staging and production issuers, this is a classic source of confusion.
Then the alg in the header. If the verifier expects RS256 and the token says HS256, it will refuse — and it should, because accepting whatever the token declares is exactly the vulnerability that made JWT libraries notorious.
FAQ
Is my token sent to a server?
No. Decoding happens entirely in your browser. Nothing is transmitted, logged, or stored — you can confirm this by opening the network tab.
Can I hide data inside a JWT?
Not with a standard signed JWT — the payload is readable by anyone. If the contents must be confidential you need JWE, the encrypted variant, which is a different format.
How do I check whether a token is valid?
Verify the signature in your backend with the appropriate library and key, and check exp, nbf, iss, and aud. This tool shows you the expiry so you can rule out the most common cause of rejection.
My token has only two parts.
That is an unsigned JWT, with alg set to none. It carries no integrity guarantee at all and should never be accepted by a production system.
Can I edit the payload and re-sign it here?
No, deliberately. Re-signing needs the secret key, and this tool never asks for one.
My token is rejected but has not expired. What else should I check?
The nbf claim in case it is not yet valid, the aud and iss claims in case the token was issued for a different audience or environment, and the alg in the header against what your verifier expects.
Can I tell whether a token was tampered with by looking at it?
No. Detecting tampering is precisely what the signature is for, and verifying it requires the key. Decoding shows you the contents but says nothing about their authenticity.
How long should an access token live?
Short — commonly five to fifteen minutes — because a leaked token cannot be revoked before it expires. Longer sessions are handled with a separate refresh token that can be revoked server-side.
⚠️ Reference Only
Output is generated based on your input and is provided for reference. Results may vary depending on your specific use case, edge cases, or environment-specific behavior. We do not guarantee accuracy of conversions, validations, or computed values.
Always verify critical outputs against official documentation or production environments. We are not responsible for any decisions or losses based on these tool results.