JWT Decoder Online – Decode and Verify JSON Web Tokens
Decode and verify JSON Web Tokens online: instantly inspect the header and payload, understand claims, check expiration and other time rules, and verify supported signatures. Decoding and verification inputs are processed locally in your browser.
JWT input
All examples are test data. Signed samples use demonstration secret starlight-demo-secret and are generated from your current time.
Results update automatically for a complete token. You can also press Ctrl/Cmd + Enter or drop a .jwt/.txt file.
Advertisement
Decoded results
Decoding does not prove authenticity. Trust token data only after signature verification with a trusted key and application-specific claim checks.
Header
Paste a token to see its decoded header.
Payload
Paste a token to see its decoded payload.
| Claim | Meaning | Value | Assessment |
|---|---|---|---|
| Paste a token to inspect its claims. | |||
Registered claims: iss issuer, sub subject, aud audience, exp expiration, nbf not before, iat issued at, and jti unique JWT ID.
Signature
Paste a token to inspect its signature segment.
Optional signature and application validation
Decode a token to see algorithm-specific key instructions.
SPKI PEM works for RSA and EC. PKCS#1 RSA PUBLIC KEY PEM is converted to SPKI locally. For JWKS, the token's kid selects the matching key.
Network notice: Fetching sends a request to that URL and exposes your IP address to its host. Cross-origin requests require CORS.
Expected application values
- ○ Signature: not checked
- ○ exp: not checked
- ○ nbf: not checked
- ○ iss: no expected value
- ○ aud: no expected value
Browser verification support
| JWT algorithms | Key input | Web Crypto operation |
|---|---|---|
| HS256/384/512 | Shared secret text | HMAC with SHA-256/384/512 |
| RS256/384/512 | RSA SPKI/PKCS#1 PEM, JWK, or JWKS | RSASSA-PKCS1-v1_5 |
| PS256/384/512 | RSA SPKI/PKCS#1 PEM, JWK, or JWKS | RSA-PSS with JOSE salt length |
| ES256/384/512 | EC SPKI PEM, JWK, or JWKS | ECDSA using P-256/P-384/P-521; support may vary by browser |
| none / JWE | Not applicable | Never verified / not decoded |
JWT anatomy: header.payload.signature
| Header | Payload | Signature |
|---|---|---|
Base64URL-encoded JSON describing alg, typ, and often kid. | Base64URL-encoded JSON claims about the subject and token. | Cryptographic integrity proof over the first two encoded segments. |
Signing formula: base64url(header) + "." + base64url(payload), signed with the algorithm declared in the header.
Worked mapping
eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0 → {"alg":"none","typ":"JWT"}eyJzdWIiOiIxMjMifQ → {"sub":"123"}eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiIxMjMifQ. → unsigned test tokenJWT terminology and registered claims are defined by RFC 7519. Signing algorithms and key formats come from the JOSE family, including JWS (RFC 7515), JWK (RFC 7517), and JWA (RFC 7518).
Security and privacy guidance
- JWT payloads are encoded, not encrypted; anyone holding a token can read them.
- Treat active tokens like credentials. Prefer revoked, redacted, or test tokens when debugging.
- Never trust
alg=none, and never paste or reuse a production HMAC secret. - Browser checks help debugging; they do not replace server-side authentication and authorization.
- Decoding and verification inputs are processed locally. A JWKS URL fetch is an explicit network request, while the surrounding production page may load ads or analytics.
JWT decoder FAQ
Do I need a secret to decode a JWT?
No. A JWT header and payload are Base64URL-encoded, so they can be decoded without a key. A secret or public key is only needed to verify the signature.
What is the difference between decoding and verification?
Decoding makes the header and payload readable. Verification uses a trusted key to prove that the signed data has not changed. A decoded token is not automatically authentic or acceptable.
Why does a JWT signature fail verification?
Common causes include the wrong secret or public key, a key in the wrong format, a changed token segment, an algorithm mismatch, or selecting the wrong key from a JWKS.
How is JWT expiration checked?
The exp claim is compared with the current browser time, with the optional clock-skew allowance applied. Expiration is separate from signature verification.
Are my token and keys uploaded?
Pasted token, secret, and key inputs are processed locally in your browser. Fetching a user-supplied JWKS URL is the exception: it sends a network request to that URL, and the page wrapper may also load analytics or ads.
What is the difference between JWT and JWE?
This tool handles three-part signed or unsigned JWTs. A five-part JWE is encrypted and needs decryption with an appropriate key, so it is detected but not decoded here.
Which algorithms and key formats are supported?
Verification supports HS256/384/512 secrets and RS256/384/512, PS256/384/512, and ES256/384/512 public keys where browser Web Crypto permits. Public keys may be SPKI PEM, RSA public-key PEM, JWK, or JWKS.
Can an expired JWT still be decoded?
Yes. Expiration does not hide the header or payload. The token can still be decoded, but the claims summary marks it expired and applications should reject it according to their authorization policy.
About and technical review
Maintained and reviewed by Starlight Robotics for Starlight Tools. Last reviewed: .
Browser support: decoding needs standard TextEncoder/TextDecoder APIs; verification needs Web Crypto. The implementation targets current Chrome, Edge, Firefox, and Safari. Exact EC and cross-origin JWKS behavior depends on browser cryptography and the JWKS server's CORS policy.