Developer & Security

JWT Decoder

Paste a JSON Web Token to read its header and payload claims, see the exp, iat and nbf timestamps as readable dates, and find out at a glance whether the token has expired. Decoding happens locally in your browser.

Free, runs in your browserUpdated October 2026

Paste the whole token, with or without the Bearer prefix. The three parts are header, payload and signature, separated by dots.

Runs locally in your browser. Nothing you paste is uploaded or stored.

Token status
–

This tool decodes the token but does not verify its signature. Anyone can create a token with any payload, so never trust these claims without verifying the signature on your server.

ClaimValue
Header
Payload
JWT decoder diagram: a sample HS256 token decodes to its claims and shows it is not expired until 2030
How the JWT Decoder works: Read any JWT's header and claims, with exp and iat turned into real dates.

How to Use the JWT Decoder

How to use the JWT decoder: paste a token, try the examples, read the status, claims, header and payload
Numbered steps on the JWT Decoder. Follow them in order.
  1. Paste the JWT, with or without the Bearer prefix.
  2. Try the expired example to see how status and dates change.
  3. Read the token status, then the claims table, header and payload below.

Paste a JSON Web Token into the box. You can include the Bearer prefix from an Authorization header; the decoder strips it along with any line breaks. The result panel shows whether the token is expired, not yet valid or still within its lifetime, then lists every claim with a plain-English name. Time claims such as exp, iat and nbf are shown as UTC dates with your local time underneath.

Below the claims you will find the decoded header and payload as formatted JSON, with buttons to copy either one. Use the example buttons to see how an expired token and a valid token look. Decoding runs entirely in your browser: the token is never uploaded, logged or stored.

How a JWT Is Built

A JWT, defined in RFC 7519, is three base64url strings joined by dots. The header says which algorithm signed the token. The payload holds the claims. The signature lets the server prove nobody changed the first two parts.

token = base64url(header) + "." + base64url(payload) + "." + base64url(signature)
signature = HMAC-SHA256(secret, header + "." + payload)   for HS256

Base64url is ordinary Base64 with - and _ instead of + and /, and no padding. Decoding it reveals the JSON, which is why a JWT payload is readable by anyone: it is encoded, not encrypted.

Worked Example

The sample token’s header decodes to {"alg":"HS256","typ":"JWT"}. Its payload contains "iat": 1767225600 and "exp": 1893456000. Those are Unix timestamps in seconds: 1,767,225,600 seconds after 1 January 1970 is 2026-01-01 00:00:00 UTC, and 1,893,456,000 is 2030-01-01 00:00:00 UTC. Because the current time is before the exp date and after the nbf date, the decoder reports Not expired. The expired example has "exp": 1700003600, which is 2023-11-14 23:13:20 UTC, one hour after it was issued.

Registered Claims

ClaimNameMeaning
issIssuerWho created and signed the token
subSubjectWho the token is about, usually a user ID
audAudienceWhich service should accept it
expExpiration timeReject the token at or after this time
nbfNot beforeReject the token before this time
iatIssued atWhen the token was created
jtiJWT IDUnique ID, used to prevent replay

Why Decoding Is Not Verifying

This decoder deliberately does not check signatures. Verifying needs the secret key (for HS256) or the issuer’s public key (for RS256 and ES256), and pasting secrets into any website is a bad habit. Anyone can write a token with "role": "admin" in the payload; only signature verification on your server, plus checks of exp, nbf, iss and aud, makes a claim trustworthy. Treat a decoded payload as information for debugging, never as proof of identity.

Debugging Tips

  • A token that expires seconds after login often means the server and client clocks disagree. Compare iat with the real time.
  • If iat or exp is a 13-digit number, the issuer used milliseconds instead of seconds, which most libraries treat as a date thousands of years away.
  • A token with five parts is a JWE, an encrypted token. Its payload cannot be read without the key.
  • Reject any token whose header says "alg": "none". The decoder flags it in red.
  • Do not put passwords or other secrets in a JWT payload, because anyone holding the token can read them.

Common Signing Algorithms

The alg header tells the server how to check the signature. HS256 uses HMAC with SHA-256 and one shared secret, so the same key signs and verifies. RS256 signs with an RSA private key and verifies with the public key, which lets many services check tokens without being able to create them. ES256 does the same with an elliptic curve key and produces shorter signatures. The decoder shows the signature length in bytes: 32 for HS256, 256 for a 2048-bit RS256 key and 64 for ES256.

Frequently asked questions

Is it safe to paste my JWT here?

Decoding runs entirely in your browser with JavaScript, and the token is never sent to a server or stored. Still, a live token grants access until it expires, so avoid pasting production tokens into any tool you do not trust.

Does this tool verify the JWT signature?

No. It only decodes the header and payload. Verifying requires the secret or public key, which should stay on your server. Always verify the signature and check exp, iss and aud before trusting any claim.

How do I read the exp value in a JWT?

exp is a Unix timestamp: the number of seconds since 1 January 1970 UTC. The decoder converts it to a date. For example, 1893456000 is 1 January 2030 at midnight UTC.

Why can anyone read my JWT payload?

A standard signed JWT is only base64url encoded, not encrypted. The signature stops tampering but does not hide the content. Use an encrypted JWE, or keep sensitive data out of the payload, if it must stay private.

What is the difference between iat and nbf?

iat records when the token was issued. nbf, not before, is the earliest time the token may be used. They are often equal, but nbf can be set later to create a token that only becomes valid in the future.

What does alg none mean in a JWT header?

It means the token has no signature at all. Accepting such tokens lets anyone forge claims, so servers must reject them. The decoder marks tokens with alg none as unsigned in red.