JWT Decoder
Read any JWT and check its signature — without sending the token anywhere.
Decoding is not verification. Anyone can create a token with any claims; only a valid signature checked with the issuer’s key proves it is genuine. Tokens, secrets and keys stay in this browser — nothing is sent anywhere.
A “Bearer ” prefix, quotes and line breaks are removed automatically.
Header
Payload
Warnings
Claims
| Claim | Value | Meaning |
|---|
Signature
About the JWT Decoder
Paste a JSON Web Token to see its header and payload as formatted JSON, with every claim explained. Dates such as exp, iat and nbf are shown in your local time and in UTC, with a live "expires in…" or "expired … ago". The decoder also catches mistakes that cause real bugs: dates written in milliseconds, missing exp, duplicate claims, alg: none and keys fetched from URLs inside the token.
Decoding only reads a token — it does not prove who made it. To check that, enter the shared secret or the issuer's public key and the signature is verified in your browser with the Web Crypto API: HS256/384/512, RS256/384/512, PS256/384/512, ES256/384/512 and EdDSA (Ed25519). Public keys can be PEM, an X.509 certificate, a JWK or a whole JWKS, matched by kid.
How to use it
- Paste the token into the box. A
Bearerprefix, quotes and line breaks are removed for you. - Read the status line, the expiry banner and the Claims table; check any Warnings.
- To check authenticity, enter the secret (HS algorithms) or the public key / JWKS (RS, PS, ES, EdDSA) and press Verify signature.
- Use Load sample to try it with a token signed on the spot, together with its secret.
Examples
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Header: {"alg": "HS256", "typ": "JWT"}
Payload: {"sub": "1234567890", "name": "John Doe", "iat": 1516239022}
iat = 18 January 2018, 01:30:22 UTC · no exp claimWith the secret your-256-bit-secret the signature verifies — and the tool warns that a 19-byte secret is shorter than the 32 bytes RFC 7518 requires for HS256.
{"exp": 1790003600000}Warning: this looks like milliseconds. JWT dates are seconds since 1970.
Most libraries would treat this token as valid for tens of thousands of years.
Common uses
- Debugging login problems: checking
aud,iss, scopes and roles in ID and access tokens. - Finding out why an API returns 401 — expired tokens, clock skew or tokens that are not valid yet.
- Confirming that a token was signed with the key from your identity provider's JWKS endpoint.
- Checking webhook or service-to-service tokens signed with a shared HMAC secret.
How a JWT is built
A signed JWT (RFC 7519) has three Base64url parts separated by dots: header.payload.signature. The header names the algorithm (alg) and often a key ID (kid); the payload holds the claims; the signature covers the first two parts (RFC 7515). Encrypted tokens (JWE, RFC 7516) have five parts and can only be read with the recipient's key.
The payload is encoded, not encrypted: anyone holding the token can read it. Never put passwords or other secrets in a JWT.
What verifying a token should involve
The JWT Best Current Practices (RFC 8725) boil down to:
- Accept only the algorithms you expect. Never accept
alg: none, and never use a public key as an HMAC secret (the "algorithm confusion" attack — this tool refuses it). - Use strong keys: at least 256-bit secrets for HS256 and 2048-bit RSA keys (RFC 7518).
- After the signature, check
iss,aud,expandnbf— a correctly signed token can still be expired or meant for another service. - Take keys from your own configuration or the issuer's published JWKS, never from
jku,x5uorjwkvalues inside the token.
Limitations
- Verification uses your browser's Web Crypto API. Algorithms it does not provide (for example ES256K or Ed448) can be decoded but not verified.
- Private keys in PEM form are refused on purpose: verification only needs the public key.
- Encrypted tokens (JWE) cannot be decrypted here; only their header is shown.
- The expiry check uses your device's clock. If it is wrong, the "expires in" times will be too.
Privacy
Everything happens in your browser. What you enter or open here is not uploaded or stored by MySmartCoPilot.
Frequently asked questions
Is it safe to paste a real token here?
Decoding and verification run entirely in your browser; the token, secret and keys are never sent to a server or stored. Still, a valid token is a password-like credential — prefer expired or test tokens, and revoke any live token you have shared somewhere.
The payload decoded fine — does that mean the token is valid?
No. Anyone can create a token with any payload. Only a signature that verifies with the issuer's key shows the token is genuine and unchanged, and even then your server must also check the issuer, audience and expiry.
Why does verification say "invalid signature"?
Either the token was changed after it was signed, or you entered a different key: a wrong or rotated secret, a key from another environment, or a secret that is stored Base64-encoded (choose Base64 as the secret format).
What do exp, iat and nbf mean?
exp is when the token expires (it must not be accepted on or after that moment), iat is when it was issued, and nbf is the moment before which it must not be accepted. All three are numbers of seconds since 1 January 1970 UTC.
Which public key formats can I use?
A PEM public key (-----BEGIN PUBLIC KEY----- or BEGIN RSA PUBLIC KEY), a PEM X.509 certificate, a single JWK, or a JWKS such as the one from your provider's /.well-known/jwks.json — the key is picked by the token's kid.