JWT Decoder and Validator
Paste a JSON Web Token to read its header and payload, see exp, iat and nbf as readable dates, and check that the token is well formed. You can also check an HS256 or RS256 signature with your secret or public key. Decoding runs entirely in your browser and nothing you paste is sent anywhere.
What is inside a JWT
A signed JWT is three base64url strings joined by dots: header.payload.signature. This is the JWS Compact Serialization from RFC 7515. The header and payload are JSON objects. base64url is base64 with the URL-safe alphabet (- and _ in place of + and /) and with all trailing = characters left out (RFC 7515, section 2). For plain base64 outside a token, try Tacetra's free Base64 encoder and decoder.
-
Header. Describes the token. The
algparameter names the signing algorithm and must be present (RFC 7515, section 4.1.1). Other common parameters aretypandkid. - Payload. For a JWT this is the Claims Set, a JSON object of claims. Claim names must be unique (RFC 7519, section 4).
- Signature. A signature or MAC over the first two parts, so any change to them is detected by someone who holds the right key.
A token with five parts is a different thing: an encrypted JWT (JWE, RFC 7516). Its payload cannot be read without the decryption key, and this page tells you so instead of guessing.
The registered claims
RFC 7519, section 4.1, defines seven optional claims. The page checks their types.
| Claim | Meaning | Value type |
|---|---|---|
iss |
Issuer: who created the token | String or URI |
sub |
Subject: who the token is about | String or URI |
aud |
Audience: who the token is for | String, or array of strings |
exp |
Expiration time | NumericDate |
nbf |
Not before: earliest time to accept it | NumericDate |
iat |
Issued at | NumericDate |
jti |
JWT ID: a unique identifier | String |
Reading exp, nbf and iat
These three are a NumericDate: a JSON number of seconds since 1970-01-01T00:00:00Z UTC, ignoring leap seconds, and it may have a fractional part (RFC 7519, section 2). The page shows each one in UTC, in your local time zone and relative to now.
- The current time must be before
exp. A token is not to be accepted on or after its expiration time (RFC 7519, section 4.1.4), so the page reports a token as expired when now equalsexp. - A token is not to be accepted before
nbf(RFC 7519, section 4.1.5). - RFC 7519 lets implementers allow a small leeway, usually no more than a few minutes, for clock skew. This page applies none, so a token a few seconds past its exp shows as expired.
Decoding is not verifying
Anyone can read a JWT payload, because base64url is an encoding and not encryption. Reading it tells you nothing about whether it is genuine. Only a signature check with the right key can show that the header and payload were not changed.
- What the signature check does. It works for HS256 (HMAC using SHA-256) and RS256 (RSASSA-PKCS1-v1_5 using SHA-256), the two algorithms RFC 7518 marks as Required and Recommended. It uses your browser's WebCrypto, and it was tested against the RFC 7515 examples and tokens signed by other software.
-
What it does not do. Other algorithms such as ES256, PS256 or HS512 are decoded but their signatures are not checked, and the page says so. A valid signature also does not prove the issuer is trusted or that
aud,issand the times suit your application: check those yourself. -
Unsecured tokens. A header with
"alg":"none"means no signature at all (RFC 7518, section 3.6, and RFC 7519, section 6). The page decodes it and warns you. Never accept such a token as proof of anything.
What the validation checks
- Three dot-separated parts, each valid base64url, with the right characters, no padding and a possible length.
- Header and payload are valid UTF-8 and valid JSON objects, with no repeated names.
- The header has a string
alg, and the signature part is empty exactly whenalgis none. - Registered claims have the types RFC 7519 gives them, and the time claims make sense together.
Study and related tools
Need to turn a number of seconds into a date for something else? Use the Unix timestamp converter. More free utilities are on the free tools page.
JWT decoder FAQ
Is it safe to paste my token here?
The page decodes in your browser and has no code that sends the token or key anywhere. Even so, treat a live token like a password: it may let someone act as you until it expires, so prefer expired or test tokens when you can.
Why does my token say it is not a JWT?
A JWT payload must be a JSON object. If the middle part decodes to something else, the token is a plain JWS or another format, and the page shows the decoded text.
Why are exp and iat numbers and not dates?
They are NumericDate values, seconds since 1 January 1970 UTC. The page converts them for you.
Why does a valid token show as expired?
Its exp time has passed. A valid signature and an expired token are separate facts: the signature shows the token is unchanged, and exp says when it stopped being acceptable.
Token structure follows RFC 7515 (JSON Web Signature), claims follow RFC 7519 (JSON Web Token) and algorithm names follow RFC 7518, all checked on rfc-editor.org on 8 November 2026. The decoder was tested on the example tokens in the RFCs, on tokens signed with Python and Node.js, and on malformed tokens.