JWT Decoder

Decode a JWT header and payload, check the standard claims and see expiry status - locally, without sending the token anywhere.

Converter Encoders & Utilities Runs in your browser
Paste the full token. Signature verification requires the key and is not performed here.

Result

Algorithm
HS256
Type
JWT
Status
valid
Expires
2026-07-26 23:00:00 UTC
Key ID (kid)
not set
Signature present
yes (not verified here)
Header
{
  "alg": "HS256",
  "typ": "JWT"
}
Payload
{
  "sub": "1234567890",
  "name": "Netvorx Example",
  "iat": 1785103200,
  "exp": 1785106800,
  "role": "engineer"
}

Claims

ClaimMeaningValue
subSubject1234567890
namecustom claimNetvorx Example
iatIssued at1785103200 (2026-07-26 22:00:00 UTC)
expExpires at1785106800 (2026-07-26 23:00:00 UTC)
rolecustom claimengineer
No verification
This decodes only - it does not verify the signature, which requires the signing key. A decoded token proves nothing about authenticity, and any server that trusts an unverified token is exploitable.

About JWT Decoder

A JWT is three base64url segments: header, payload and signature. The first two are readable by anyone holding the token - so a JWT is authenticated, not confidential. This decodes both locally and flags the claims that commonly cause problems.

Revocation, and why it is hard

A signed token is valid until it expires because verification is local — that is the whole point, and it is also the problem. Logging a user out, disabling an account or changing a role has no effect on tokens already issued. The practical pattern is short-lived access tokens (minutes) paired with a refresh token checked against server state, plus a version or session claim that can invalidate a family of tokens. Anything longer than an hour without a revocation story is a security decision, not an implementation detail.

What decoding does and does not prove

Decoding shows what the token claims. Only signature verification with the correct key proves the claims are authentic. The classic vulnerability is a server that decodes and trusts without verifying, or one that accepts alg: none, or one that lets the token choose between HMAC and RSA verification - the algorithm confusion attack.

Common use cases

  • Checking whether a 401 is caused by an expired token.
  • Inspecting which scopes or roles an identity provider issued.
  • Debugging clock skew between an issuer and a validator.

Edge cases and gotchas

  • Never paste a production token into an online decoder you do not control. This one runs locally, but the habit is dangerous.
  • JWT payloads are not encrypted - do not put anything sensitive in them.

Frequently asked questions

What is the algorithm confusion attack?
A server that lets the token choose its verification algorithm can be tricked into verifying an RS256 token as HS256, using the public key as an HMAC secret. Pin the expected algorithm server-side and reject anything else.
My token is valid but the server rejects it - why?
Common causes: clock skew making nbf or iat appear in the future, an audience mismatch, or the signing key having rotated. Check kid against the issuer JWKS.