About the JWT Decoder
This JWT decoder splits a JSON Web Token into its three parts and decodes the header and payload into readable, pretty-printed JSON. It shows the signing algorithm, explains each standard claim, converts the iat, nbf and exp timestamps into UTC dates, and tells you whether the token is valid, expired or not yet active at the moment you choose.
It is built for developers debugging login flows, API gateways and OAuth or OpenID Connect integrations — for example checking why an API returns 401, confirming which scopes or roles a token carries, or seeing exactly when a session will time out. Decoding happens entirely in your browser; the token is never sent anywhere.
Decoding is not verification: anyone can read a JWT’s payload, because it is only base64url-encoded, not encrypted. This tool does not check the signature, so never trust claims from a token until your server has verified its signature with the correct key. The validity check uses the date and time you enter (UTC) so results are reproducible.
How to use the jwt decoder
- 1Paste the JWT (a "Bearer " prefix is removed automatically).
- 2Read the decoded header and payload JSON.
- 3Set the date and time (UTC) to check the token against.
- 4Check the status, expiry time and time remaining.
- 5Use the claims table to see what each field means.
Formula and method
A JWT in compact form is three base64url strings joined by dots. base64url is ordinary base64 with "-" and "_" in place of "+" and "/" and the "=" padding removed. The decoder restores the standard alphabet, decodes each of the first two parts to UTF-8 text and parses it as JSON; the third part is the signature bytes, which are shown but not verified.
Time claims (iat, nbf, exp) are NumericDate values — seconds since 1970-01-01 00:00:00 UTC. The token is valid at time t when nbf ≤ t < exp. Time until expiry is exp − t in seconds, and lifetime is exp − iat.
- iat
- Issued-at time (Unix seconds)
- nbf
- Not-before time (Unix seconds)
- exp
- Expiration time (Unix seconds)
- t
- The check date and time you enter, in UTC
Worked examples
HS256 session token, 30-day lifetime
The header says the token is signed with HMAC-SHA256. It was issued at 1790000000 (21 Sep 2026 14:13:20 UTC) and expires 2,592,000 seconds (30 days) later. Checked at 1 Oct 2026 12:00 UTC it still has 1,736,000 seconds — 20 days, 2 hours and 13 minutes — left.
Expired one-hour API token
This RS256 token was issued at midnight UTC on 1 January 2026 with a one-hour lifetime (exp − iat = 3,600 s). Checked at 02:00 UTC it expired 3,600 seconds earlier, so an API would reject it with 401.
Malformed token
A compact JWT always has exactly three dot-separated parts. With only two, the input cannot be a valid signed token.
Frequently asked questions
Is it safe to decode a JWT online?+
This decoder runs entirely in your browser and never transmits the token. Still, treat production tokens like passwords: they grant access until they expire, so avoid pasting live tokens into tools you do not trust.
Does decoding a JWT verify it?+
No. Decoding only base64url-decodes the header and payload, which anyone can do. Verification recomputes the signature with the secret or public key and must be done on your server before trusting any claim.
Are JWT payloads encrypted?+
Standard signed JWTs (JWS) are not encrypted — the payload is readable by anyone who holds the token. Do not put secrets in it. Encrypted tokens use JWE, which has five parts instead of three.
What do iat, nbf and exp mean?+
They are registered claims from RFC 7519: iat is when the token was issued, nbf is the time before which it must not be accepted, and exp is when it expires. All are Unix timestamps in seconds, UTC.
Why is my token rejected even though it has not expired?+
Common causes are a signature that does not match the server’s key, a wrong aud or iss claim, an nbf in the future due to clock skew between servers, or the token being revoked on the server side.