How to use the JWT decoder
- Paste the token into the box — the long text that starts with
eyJ. A copiedAuthorization: Bearer …header, quotes around the token or line breaks inside it are cleaned up for you. - Read the decoded header and payload as formatted JSON, the expiry status at the top, and the standard claims with their dates in your time zone and how long ago or how far ahead they are.
- To check the signature, enter the key: the shared secret for HS256, HS384 and HS512, or the public key for RS, PS, ES and EdDSA tokens, as a PEM block, a JWK or a whole JWKS. The result says Valid signature or Invalid signature.
What is inside a JWT
A JSON Web Token (RFC 7519) is three pieces of base64url text joined by dots: header.payload.signature. The header and the payload are JSON objects, merely encoded — not encrypted — which is why they always start with eyJ, the encoding of {". The header names the signing algorithm (alg); the payload holds the claims, statements about the user or session. The signature is computed over the first two parts exactly as written, so changing a single character of either makes it fail.
| Claim | Name | Meaning |
|---|---|---|
iss | Issuer | Who created and signed the token, often the login server’s URL |
sub | Subject | Whom the token is about, usually a user ID |
aud | Audience | The service or services that should accept it; a token for one API must be rejected by another |
exp | Expiration time | After this moment the token must be rejected |
nbf | Not before | Before this moment the token must be rejected |
iat | Issued at | When the token was created |
jti | JWT ID | A unique ID, so a server can refuse a token it has seen before |
The three dates are NumericDates: seconds since January 1, 1970 (UTC), the same numbers as Unix timestamps. A value with 13 digits is milliseconds — a common bug the decoder points out. Servers usually allow a minute or two of clock skew; the status shown here uses none.
Worked example
RFC 7515, the JSON Web Signature standard, signs this token in its first example (Appendix A.1):
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
Its header decodes to { "typ": "JWT", "alg": "HS256" } — an HMAC SHA-256 token — and its payload to { "iss": "joe", "exp": 1300819380, "http://example.com/is_root": true }. So the issuer is “joe”, there is one private claim (http://example.com/is_root), and exp 1300819380 is 2011-03-22 18:43:00 UTC: decoded in October 2026, the status read “Expired 16 years ago”. To verify it, paste the RFC’s key as a JWK,
{"kty":"oct","k":"AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow"}
and the signature shows as valid. Change one letter of the payload and it becomes invalid.
The token already in the box is the well-known example from jwt.io; its secret is your-256-bit-secret. That secret is 19 bytes, shorter than the 32 bytes RFC 7518 requires for HS256, so the decoder flags it once you verify.
Verifying the signature
- HS256, HS384, HS512 use one shared secret to sign and to verify. Type it as plain text, or paste it as a JWK of type
octwhen it is Base64-encoded. - RS256 and PS256 (RSA) and ES256 (elliptic curves P-256, P-384 and P-521 for ES384 and ES512) are signed with a private key and checked with the matching public key. Login providers publish their public keys as a JWKS at the
jwks_urilisted in/.well-known/openid-configuration; paste that JSON and the decoder picks the key whosekidmatches the token. - Verification uses your browser’s built-in Web Crypto, the same code that secures HTTPS. Keys are used only for checking: nothing is signed, stored or sent.
Security tips
- Decoding is not verifying. Anyone can read a JWT, and anyone can write one with any claims. Trust a token only after its signature,
exp,issandaudhave been checked by your server. - Reject alg “none”. It marks an unsigned token, and accepting it lets an attacker forge any identity (RFC 8725, the JWT best-practice guide).
- Pin the algorithm. A server that verifies an HS256 token with its RSA public key as the “secret” can be fooled by a forged token, the algorithm confusion attack. The decoder refuses that combination.
- Don’t paste live production tokens into websites — including this one. This page decodes everything locally and sends nothing, but a valid token is a password for as long as it lasts. Use expired or test tokens when you can, and never paste a private key: verification needs only the public key.
- Keep secrets out of payloads. They are readable by anyone who holds the token. If the claims themselves must stay confidential, use an encrypted JWT (JWE), which has five parts; the decoder recognizes those and shows their header.
To decode a single base64url part by hand, use Base64 decode; to read a timestamp in other formats, the epoch converter.
Frequently asked questions
Is it safe to paste a JWT here?
The token is decoded and verified by JavaScript in your browser and never sent to a server, and the page doesn’t save it. Still, a valid token works like a temporary password, so the safest habit with any website is to paste expired or test tokens, and to sign out (which revokes some tokens) if you pasted a live one somewhere you don’t trust.
Can I decode a JWT without the secret?
Yes. The header and payload are only base64url-encoded, so no key is needed to read them. The secret or public key is needed only to verify the signature — to prove the token is genuine and unchanged.
Why does the decoder say “Invalid signature”?
Either the token was changed after it was signed, or the key isn’t the one that signed it: a secret from another environment, a missing or extra character, the wrong public key after a key rotation, or a secret that is meant to be Base64-decoded first (paste it as a JWK of type oct).
What is the difference between a JWT, a JWS and a JWE?
A JWS (RFC 7515) is signed data in three parts; a JWE (RFC 7516) is encrypted data in five parts. A JWT (RFC 7519) is a set of claims carried in one of them — almost always a JWS, which is why “JWT” usually means a signed token.
How do I know when a token expires?
Look at Expires (exp): the decoder shows it as a date in your time zone and as “in 2 days” or “3 hours ago”. A token without an exp claim never expires by itself, which is risky for access tokens.
Last updated: October 16, 2026