Delimiter.live
Developer Tools Runs in your browser Free · no account

JWT Decoder

The JWT decoder splits a JSON Web Token into its header and payload, formats both as readable JSON, and interprets the standard time claims so you can see when the token was issued and whether it has expired. It does not verify the signature and never asks for your key.

JSON Web Token 0 characters
Decoded token

Your result will appear here.

Not sure where to start? Use Load example.

Results update automatically and are calculated on your device. Nothing you type is sent to a server.

Runs in your browser. Processing happens entirely in your browser. Nothing you enter is sent to Delimiter.live.

How to use the JWT Decoder

  1. Paste the token — all three dot-separated parts.
  2. Read the decoded header to see the signing algorithm and the payload to see the claims.
  3. Check the issued-at, not-before and expiry claims, which are shown as readable dates.

Example

Input
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMifQ.sig
Output
Header:  { "alg": "HS256" }
Payload: { "sub": "123" }
Signature: not verified

The registered claims

RFC 7519 reserves seven claim names. All are optional; which ones a token carries is up to whoever issued it. The three dates are Unix timestamps in seconds, which the decoder converts to readable dates.

Claim Name What it means
iss Issuer Who created and signed the token. Check it against the issuer you expect
sub Subject Who the token is about — usually a user ID
aud Audience Who the token is for. A service should reject a token whose audience is not itself
exp Expiration time After this moment the token must be rejected
nbf Not before Before this moment the token must be rejected
iat Issued at When the token was created. Useful for spotting tokens older than you allow
jti JWT ID A unique identifier, used to stop the same token being replayed

Common use cases

  • Checking why an API rejected a token — usually an expired exp claim or the wrong audience.
  • Confirming which claims your identity provider actually issues.
  • Reading the algorithm in the header while debugging a signature mismatch.

Limitations and things to watch for

  • The signature is not verified and cannot be, because verification requires the secret or public key. Decoded claims must never be trusted until your own backend has verified the signature and checked that the algorithm is the one you expect.
  • A JWT payload is Base64URL-encoded, not encrypted. Anyone holding the token can read every claim in it, so tokens should not contain sensitive personal data.
  • Encrypted tokens (JWE, five dot-separated parts) cannot be decoded without the key and are reported as such.

Frequently asked questions

Does this verify the signature?
No, and that is intentional. Verifying would mean pasting your signing secret into a web page. The decoder reads only the header and payload, and always labels the signature as unverified.
Is it safe to paste a real token here?
Decoding happens entirely in your browser and the token is never transmitted. That said, a live access token is a credential — prefer an expired or test token, and treat any token you have shared elsewhere as compromised.
Is a JWT encrypted?
No. A standard JWT is signed, not encrypted, and its payload is readable by anyone who has the token. Never put passwords or sensitive personal data in a JWT.
What does the exp claim mean?
It is the expiry time as a Unix timestamp. The decoder converts it to a readable date and tells you whether the token has already expired relative to your device clock.

Share this tool