homedeveloper toolsjwt decoder

JWT Decoder

Decode JWT header and claims, check expiry in IST, verify HS256 signatures

Decoded in your browser. The token is never sent anywhere. A "Bearer " prefix is ignored.
Token status
Paste a JWT to see its header, claims and expiry.

Runs entirely in your browser. Nothing you type or upload is sent to us or stored.

Results are for general guidance. Please check anything important before relying on it. Terms of use

How to Use

  1. Paste a JWT into the box. A leading Bearer and line breaks are ignored. No token handy? Click Try an example. Clear empties the box again.
  2. The Token status shows at once whether it has expired or how long it is still valid.
  3. Check the claims table: iss, sub, aud, exp, nbf and iat are explained, with times in IST and your local time.
  4. Scroll down to read the pretty-printed Header and Payload JSON, and copy either one.
  5. For HS256, HS384 or HS512 tokens, enter the secret to verify the signature. Only use test secrets, never production ones.

What is a JWT?

A JSON Web Token (JWT, often pronounced "jot") is a compact, signed piece of JSON that a server gives to a client after login. The app sends it back with each request, usually in an Authorization: Bearer … header, so the server knows who is calling without looking up a session. JWTs are defined in RFC 7519, and most modern login systems use them, as do OAuth 2.0 and OpenID Connect providers and mobile app back ends. This JWT decoder shows what's inside a token and when it expires.

The three parts

A JWT is three Base64URL-encoded parts joined by dots:

header.payload.signature
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 . eyJzdWIiOiIxMjM0NTY3ODkwIi… . SflKxwRJSMeKKF2QT4fw…
{"alg":"HS256","typ":"JWT"} {"sub":"1234567890",…}
  • Header: the signing algorithm (alg) and token type.
  • Payload: the claims, meaning facts about the user and the token.
  • Signature: computed over header.payload with a secret or private key. It proves the first two parts haven't been changed.

Base64URL is ordinary Base64 with - and _ instead of + and /, and with the = padding removed. It's an encoding, not encryption: anyone holding a JWT can read its payload, exactly as this tool does. Never put passwords, Aadhaar or PAN numbers, or other secrets in a JWT payload.

Registered claims

ClaimNameMeaning
issIssuerWho created the token, e.g. your auth server's URL
subSubjectWho it is about, usually a user ID
audAudienceWhich API or app should accept it
expExpiration timeReject the token after this moment
nbfNot beforeReject the token before this moment
iatIssued atWhen the token was created
jtiJWT IDUnique ID, used to stop a token being replayed

Times are NumericDate values, which means seconds since 1 January 1970 UTC, not milliseconds. Example: "exp": 1791786600 is 12 October 2026, 06:30 UTC, which is 12:00 noon IST (UTC+05:30). A 13-digit value is almost always a bug where milliseconds were used, and the tool flags it.

Decoding vs verifying

Decoding just reads the JSON and needs no key. Verifying recomputes the signature and is the only thing that proves a token is genuine. This tool can verify HMAC tokens (HS256, HS384, HS512) if you enter the shared secret; it uses your browser's Web Crypto API. Tokens signed with RS256, ES256 or other public-key algorithms must be verified with the issuer's public key, normally published at a JWKS URL, and your server's JWT library does that.

When your API validates a token it should check the signature using an algorithm it expects (not whatever the header claims), then exp, nbf, iss and aud. A token with "alg": "none" is unsigned and must always be rejected.

Troubleshooting with this tool

  • "Expired n minutes ago" while the server says 401: refresh the token. If it seems to expire too early, compare your server's clock with real time; small clock differences matter.
  • Invalid signature with the right secret: check whether the secret is stored Base64-encoded (turn on the switch), and that the token wasn't cut off when copied.
  • Five parts instead of three: that's an encrypted JWE. Its payload can only be read with the decryption key.
  • Privacy: decoding happens entirely in your browser. Even so, treat live tokens like passwords: anyone holding one can act as that user until it expires.

Frequently Asked Questions

Yes, as far as this site goes: the token is decoded in your browser and never sent to any server. Still, a valid JWT works like a temporary password, so avoid pasting live production tokens into any website and prefer tokens from test or expired sessions.

Yes. The header and payload are only Base64URL-encoded, not encrypted, so anyone with the token can read them. The signature stops people from changing the data, not from reading it. Don't put passwords or personal identifiers like Aadhaar or PAN numbers in a JWT.

Look at the exp claim. It's the expiry time in seconds since 1 January 1970 UTC. This tool converts it to IST and your local time and shows 'Expired n minutes ago' or 'Valid for…' automatically.

No. Decoding only reads the contents. Verification recomputes the signature with the secret or public key. Here you can verify HS256, HS384 and HS512 tokens with their secret; RS256 and ES256 tokens need the issuer's public key and should be verified on your server.

HS256 uses one shared secret to both sign and verify, so every service that verifies tokens can also create them. RS256 uses a private key to sign and a public key to verify, so many services can check tokens while only the auth server can issue them.

Probably because the exp value was written in milliseconds instead of seconds. A 13-digit exp like 1791786600000 is read as seconds by JWT libraries and lands tens of thousands of years ahead. The tool warns when it sees this.