JWT Decoder & Verifier

Decode and verify JSON Web Tokens (JWT) in your browser. HS256, RS256, ES256 supported. Tokens and keys never leave your device.

Runs in your browser — nothing uploaded

JWT

Paste a JWT above to decode it instantly.

Use this free JWT decoder to instantly inspect any JSON Web Token, read its header and payload claims, and verify its signature against a shared secret or a public key — all without sending the token anywhere. It is built for debugging auth flows, inspecting access tokens, and confirming that a token was signed by the issuer you expect.

Private by design — your data never leaves your device

How to use it

No account, no upload — it all happens on your device.

Paste your JWT into the input box. The header and payload decode instantly.

Check the status badges to see whether the token is currently valid, expired, or not yet active.

To verify the signature, paste the secret (HMAC) or PEM public key (RSA / ECDSA) into the Signature panel and click Verify signature.

Use the Copy button on any panel to grab the decoded JSON or the raw signature.

Anatomy of a JWT

Three Base64URL-encoded parts joined by dots.

A JWT looks like header.payload.signature. Each part is a separate Base64URL-encoded blob:

Header — a JSON object describing how the token is signed: alg (HS256, RS256, etc.) and typ (almost always JWT).
Payload — the claims. Standard ones include iss (issuer), sub (subject), aud (audience), exp (expiry), iat (issued at), and jti (token ID). Anything else is a custom claim.
Signature — the cryptographic proof. Computed over the encoded header + payload using the algorithm named in the header.

Crucially: the header and payload are encoded, not encrypted. Anyone with the token can read the claims — never put secrets in a JWT.

Signature algorithms at a glance

When to pick which alg.

Family	Algorithms	Key	Best for
HMAC	HS256, HS384, HS512	Shared secret	Single trusted service issuing and consuming tokens
RSA-PKCS1	RS256, RS384, RS512	Private + public keypair	OAuth/OIDC providers, third-party token validation
RSA-PSS	PS256, PS384, PS512	Private + public keypair	Newer deployments — same use case as RS, stronger padding
ECDSA	ES256, ES384, ES512	Private + public EC keypair	Smaller keys, faster signing — common in mobile and IoT

If the consumer is a different service than the issuer (the common OAuth case), use asymmetric signing — RS256 or ES256 — so consumers only need the public key. Reserve HMAC for tokens that never leave one trust boundary.

Common JWT pitfalls

Trusting alg blindly. Some old libraries accept alg: none or downgrade RS256 to HS256, letting attackers sign tokens with your public key as the secret. Always pin the expected algorithm on the verifier.
Long-lived tokens.Once issued, a JWT is valid until it expires. If exp is days away, you can't revoke it without extra infrastructure. Keep access tokens short-lived (minutes to an hour) and pair them with refresh tokens.
Putting PII in the payload. Anyone who sees the token can decode it. Use opaque IDs, not emails or names, when the token may be logged or stored.
Skipped iss / aud checks. Tokens from one tenant or app can be replayed against another if you only validate the signature. Always check issuer and audience.
Clock skew. A token that just barely passes exp on one server may be rejected by another. Allow ±60 seconds of leeway on verification.

Frequently asked

Is my token or signing key sent to a server?

No. Decoding and signature verification both run entirely in your browser using the built-in Web Crypto API. Your JWT, secrets, and public keys never leave your device.

Which signature algorithms can it verify?

HMAC (HS256, HS384, HS512), RSA-PKCS#1 v1.5 (RS256, RS384, RS512), RSA-PSS (PS256, PS384, PS512), and ECDSA (ES256, ES384, ES512). The algorithm is read from the JWT header automatically — paste a shared secret for HMAC, or a PEM-formatted public key for RSA and ECDSA.

Why does it say my token is expired?

The 'exp' claim in the payload is a Unix timestamp for when the token stops being valid. If that moment is in the past, the token is expired. Look at the Known claims table to see the exact expiry date and relative time.