Skip to content
koducathome

JWT Decoder

Decode a JSON Web Token to read its header and claims, check expiry, and optionally verify its signature with a secret or public key.

How to use this tool

Steps for using the JWT Decoder.

  1. Paste your JWT into the Encoded Token box, or click Sample Token. Its header, payload and signature are colour-coded, and a leading Bearer is removed automatically.
  2. Read the Decoded Header and Decoded Payload. Switch to Claims Breakdown to see what each claim means and when iat, nbf and exp fall.
  3. To verify the signature, enter the HMAC secret or the issuer's public key (JWK, JWK Set or PEM) under JWT Signature Verification.
  4. Check the status lines under the token: Valid JWT, Signature Verified or Invalid Signature, and whether the token has expired.
  5. Your server must still check iss, aud, expiry and the allowed algorithms — a valid signature alone is not enough.

Common JWT claims

sub
Subject — identifies the user or entity
iss
Issuer — who issued the token
aud
Audience — intended recipient
iat
Issued at — when the token was created
exp
Expiration time — when the token expires
nbf
Not before — token is not valid before this time
jti
JWT ID — unique identifier, used to prevent replay

Related tools

View all

What a JWT contains — and what decoding does not tell you

A JSON Web Token in its common signed form (JWS compact serialisation) is three Base64url-encoded segments joined by dots: a header describing how it was signed (alg, usually typ and sometimes a key ID kid), a payload of claims, and a signature over the first two segments. Base64url is an encoding, not encryption, so anyone holding the token can decode the header and payload exactly as this tool does. Never put secrets in JWT claims. Tokens with five segments are encrypted JWTs (JWE); only their protected header is readable without the decryption key.

The registered claims from RFC 7519 have precise meanings. iss (issuer) identifies who created the token, typically your identity provider's URL. sub (subject) identifies the user or service the token is about. aud (audience) names the intended recipient — a string or an array of strings — and an API must reject a token whose audience does not include it. exp (expiration time) is the moment after which the token must be refused; nbf (not before) is the moment before which it must be refused; iat (issued at) records when it was created. jti is a unique token ID that can be used to detect replays or revoke a single token.

The three time claims are NumericDate values: whole seconds since 1970-01-01T00:00:00Z, not milliseconds. A common bug is writing Date.now() (milliseconds) into exp, producing a token that expires tens of thousands of years from now; this decoder flags values that look like milliseconds. The validity status uses your device's clock, and real servers usually allow a small clock-skew leeway of 30–60 seconds, so a token that expired seconds ago may still be accepted briefly.

Decoding is not verification. Only checking the signature with the right key — the shared HMAC secret for HS256, or the issuer's public key for RS256 and ES256 — proves the token was issued by who it claims and has not been modified. Servers must also pin an allow-list of algorithms; accepting alg: "none" or letting the token choose its own algorithm are well-known vulnerabilities. Use this page to read and debug tokens, and see the decode JWT guide for how verification works in practice.

Limitations

  • Signature verification is optional and needs the right key: the shared secret for HS256/384/512, or the public key for RS, PS, ES and EdDSA tokens. X.509 certificates and PKCS#1 PEM keys must be converted to a SPKI PUBLIC KEY first.
  • Verifying a signature here does not check iss, aud or which algorithms your application allows — your server must enforce those.
  • Encrypted tokens (JWE) cannot be decoded without the key; only the protected header is shown.
  • Expiry status uses your device's clock and applies no leeway.
  • Only the compact serialisation is supported, not the JSON serialisation of JWS/JWE.

Frequently asked questions

How do I verify a JWT signature here?

Paste the token, then enter the key under JWT Signature Verification: the shared secret for HS256/HS384/HS512 tokens, or the issuer's public key for RS256, PS256, ES256 or EdDSA tokens — as a JWK, a JWK Set (the key matching the token's kid is used) or a PEM PUBLIC KEY. Verification uses your browser's Web Crypto API; neither the token nor the key is sent anywhere. Never paste a private key.

Is it safe to paste my JWT here?

Decoding happens entirely in your browser; the token is never uploaded, logged or sent to analytics. Even so, a valid access token works like a password until it expires, so prefer expired or test tokens and avoid sharing screenshots of live ones.

Why does the tool say the token is valid when my API rejects it?

"Valid now" only means the current time is between nbf and exp. Your API also checks the signature, the algorithm, the issuer (iss) and the audience (aud), and may check scopes or revocation. Any of these can fail even when the time claims are fine.

Can I see the secret or key from the signature?

No. The signature is an HMAC or digital signature value; it does not contain the key and the key cannot be recovered from it — unless an HMAC secret is short or guessable, in which case it can be brute-forced offline. That is why HS256 secrets should be at least 256 random bits.

What is the difference between iat, nbf and exp?

iat records when the token was issued, nbf is the earliest time it may be used, and exp is the time after which it must be rejected. All three are seconds since the Unix epoch; use the Timestamp Converter to convert other values.

Why does decoding fail with "not valid Base64url"?

JWT segments use the URL-safe Base64 alphabet (- and _, no = padding). If the token was copied from a URL-encoded query string, a log that wraps lines, or was cut off, one of the segments will contain invalid characters or an impossible length.