Decode and verify JSON Web Tokens privately
The JWT Decoder shows what is inside a JSON Web Token: the header (algorithm and key ID), the payload claims, and the signature. Time claims such as exp, iat and nbf are converted to readable local dates, and a status badge tells you at a glance whether the token has expired.
Decoding alone does not prove a token is genuine, so the tool can also verify the signature: enter the shared secret for HS256, HS384 or HS512 tokens, or paste the issuer’s public key — PEM, certificate, JWK or a whole JWKS — for RS256, PS256 and ES256 tokens and their 384 and 512 variants.
Tokens are bearer credentials: anyone who has one can use it until it expires. That is why everything here runs in your browser with the Web Crypto API. Your token, secret and keys never leave your device, are never logged and are not stored.
How to use the JWT Decoder
- Paste the token into JSON Web Token. A leading “Bearer ” or quotes are removed automatically.
- Read the colour-coded parts and the Header and Payload panels. Badges show the algorithm and whether the token is valid, expired or not yet active.
- Check the Registered claims table for the issuer, subject, audience and exact expiry time in your time zone.
- To verify, enter the Secret (tick the Base64 box if your secret is stored encoded) or paste the Public key. The result appears immediately.
- Use the copy buttons to take the decoded JSON elsewhere, or press Sample token to see a valid example.
JWT Decoder features
Instant decoding
Header and payload are Base64URL-decoded as UTF-8 and pretty-printed, including non-English names and emoji.
Human-readable times
exp, nbf and iat are shown as local dates with “in 2 hours” or “3 days ago”, plus an expired / valid badge.
Signature verification
HS256/384/512 with a secret; RS256/384/512, PS256/384/512 and ES256/384/512 with a public key; EdDSA where your browser supports it.
Flexible key input
PEM public keys (SPKI or PKCS#1), X.509 certificates, single JWKs and JWKS sets matched by kid.
Clear error messages
Wrong number of parts, invalid Base64URL characters, non-JSON headers, DER-encoded ECDSA signatures and encrypted JWE tokens are each explained.
Safety checks
Warnings for alg: none tokens, missing expiry and HMAC secrets shorter than RFC 7518 requires.
How a JWT is put together
A JWT (RFC 7519) is three Base64URL strings joined by dots: header.payload.signature. The header says how the token is signed, for example {"alg":"HS256","typ":"JWT"}. The payload holds the claims — statements about the user and the token. The signature is computed over the first two parts, so changing even one character of the header or payload invalidates it.
The header and payload are only encoded, not encrypted. Anyone holding the token can read them, which is exactly what this decoder does. Never put passwords or other secrets in a JWT payload; if the contents must be hidden, use an encrypted JWE instead. For general Base64 work, use the Base64 encoder.
Signing algorithms at a glance
| alg | Type | Verify with | Notes |
|---|---|---|---|
| HS256 / HS384 / HS512 | HMAC with SHA-2 | Shared secret | Same secret signs and verifies; keep it at least as long as the hash (32+ bytes for HS256) |
| RS256 / RS384 / RS512 | RSA PKCS#1 v1.5 | RSA public key | Most common for OpenID Connect ID tokens |
| PS256 / PS384 / PS512 | RSA-PSS | RSA public key | Modern RSA padding |
| ES256 / ES384 / ES512 | ECDSA on P-256 / P-384 / P-521 | EC public key | Small keys and signatures |
| EdDSA | Ed25519 | Ed25519 public key | Needs a recent browser |
| none | Unsecured | — | No signature — never accept in production |
Checking a token properly
- Verify the signature with a key you trust — not one taken from the token’s own header.
- Reject tokens whose
algis not the one you expect, especiallynone. - Check
expandnbf, allowing a small clock skew of a minute or two. - Check that
issandaudmatch your identity provider and your application. - Use the Unix Timestamp Converter to work out custom time claims.
JWT Decoder FAQ
How do I decode a JWT?
Paste it into the box above. The JWT decoder splits it at the dots, Base64URL-decodes the header and payload, and shows them as formatted JSON with the registered claims explained. No secret is needed to read a token.
Is it safe to paste a production token here?
The token is processed only in your browser and is never sent anywhere, so this page does not leak it. Still, treat live tokens like passwords: prefer expired or test tokens, and revoke any token you have shared somewhere unsafe.
Why does it say “Invalid signature” when the secret is right?
Check whether your secret is stored Base64-encoded (tick the Base64 box), that there are no extra spaces, and that the token was copied in full. For RS and ES tokens, make sure you pasted the public key that matches the token’s kid.
Can this tool create or sign JWTs?
It is a decoder and verifier. The “Sample token” button signs a demo HS256 token so you can see a verified result, but it does not issue tokens for your own keys.
What is the difference between JWT, JWS and JWE?
JWT is the claims format. A JWS is a signed JWT (three parts) whose payload anyone can read; a JWE is an encrypted JWT (five parts) whose payload only the recipient can read. This tool decodes JWS tokens and shows the header of JWE tokens.
Why is my token expired when it was just issued?
Your device clock may be wrong, or the server issued it with a very short lifetime. Compare the iat and exp dates in the claims table with the current time.