Starlight Tools

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

0 characters

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.

Decoded results

Structure○ Not checked
Claims○ Not checked
Signature○ Not verified

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.

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 algorithmsKey inputWeb Crypto operation
HS256/384/512Shared secret textHMAC with SHA-256/384/512
RS256/384/512RSA SPKI/PKCS#1 PEM, JWK, or JWKSRSASSA-PKCS1-v1_5
PS256/384/512RSA SPKI/PKCS#1 PEM, JWK, or JWKSRSA-PSS with JOSE salt length
ES256/384/512EC SPKI PEM, JWK, or JWKSECDSA using P-256/P-384/P-521; support may vary by browser
none / JWENot applicableNever verified / not decoded

JWT anatomy: header.payload.signature

headerpayloadsignature
HeaderPayloadSignature
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 token

JWT 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.

Explore more tools