Developer
Encoders, converters & dev utilities
JWT Decoder & Verifier
Decode & verify JWTs in your browser — header, payload, expiry, signature. Accurate, instant and free — for United States.
100% in-browser — nothing is uploaded
A JWT has three dot-separated parts: header.payload.signature. Decoding shows what's inside — it does not prove the token is authentic. Use the verify panel below for that.
Decoding is not verifying
What's inside a JSON Web Token
A JWT is three base64url-encoded parts joined by dots: header.payload.signature. The first two are just encoded JSON — not encrypted — so anyone can read them. The signature is what makes the token trustworthy.
Header
Algorithm & type
{ "alg": "HS256", "typ": "JWT" }
- alg — the signing algorithm
- typ — the token type
Payload
The claims
{ "sub": "123", "exp": … }
- Registered claims: iss sub aud exp nbf iat jti
- Plus any custom data
- Readable by anyone — never put secrets here
Signature
The trust anchor
HMAC/RSA/ECDSA(header.payload, key)
- Computed over header + payload
- Proves the token was not altered
- Verified with the signing key
Decoding is not verifying
Reading a JWT tells you what it claims. Only checking its signature tells you whether to believe it. How that check works depends on the algorithm.
HS256 — symmetric
One shared secret
- The same secret signs and verifies
- Anyone who can verify can also forge
- Keep the secret server-side only
RS256 / ES256 — asymmetric
Private signs, public verifies
- Private key signs; public key verifies
- Verifiers can't mint new tokens
- ES256 = ECDSA on P-256; RS256 = RSA
The "alg: none" attack
Key-confusion (RS256 verified as HS256)
Expiry and time claims — exp, nbf, iat
The time claims are NumericDate values — seconds since the Unix epoch (1 Jan 1970 UTC). A token is currently valid only when the present time is at or after nbf and strictly before exp.
exp
Expiration time
Reject the token at or after this instant.
nbf
Not before
Reject the token before this instant.
iat
Issued at
When the token was created.
This tool converts the timestamps for you
Frequently asked questions
A JSON Web Token (JWT) has three base64url-encoded parts separated by dots: header.payload.signature. The header states the signing algorithm (for example HS256 or RS256) and the token type. The payload carries the claims — statements such as sub (subject), iss (issuer), exp (expiration time), iat (issued-at) and any custom data. The signature is a cryptographic value computed over the header and payload using a key; it is what lets a server confirm the token has not been altered. The header and payload are only encoded, not encrypted, so anyone can read them — never put secrets in a JWT payload.
No. Decoding just base64url-decodes the header and payload back into JSON — anyone can do it, and it proves nothing. Verifying recomputes the signature over the header and payload with the signing key and checks it matches. Only a verified token can be trusted. This tool decodes instantly and offers a separate verify step where you supply the HMAC secret (HS256) or the public key (RS256/ES256).
HS256 is symmetric: the same secret both signs and verifies, so every party that can verify can also forge tokens. RS256 (RSA) and ES256 (ECDSA on the P-256 curve) are asymmetric: a private key signs and a matching public key verifies, so verifiers can check tokens without being able to mint them. The security implication is that you must never verify an RS256 or ES256 token with a symmetric secret — a classic key-confusion attack tricks a naive verifier into treating the RSA public key (which is not secret) as an HMAC key. This tool refuses that combination.
The JWT spec defines an "none" algorithm meaning the token is unsigned. If a verifier honours the header's alg field blindly, an attacker can strip the signature, set alg to none, and forge any claims they like — a complete authentication bypass. The defence is to never accept alg none and to pin the expected algorithm on the server rather than trusting the header. This tool always rejects alg none and will not report such a token as verified.
These are registered time claims, expressed as NumericDate (seconds since the Unix epoch, 1 January 1970 UTC). exp (expiration time) is the moment after which the token must be rejected. nbf (not before) is the moment before which it must be rejected. iat (issued at) records when it was created. A token is currently valid only if the present time is at or after nbf and strictly before exp. This tool shows each time claim as a human-readable UTC timestamp plus a relative age, and flags whether the token is active, expired or not-yet-valid.
No. Decoding and signature verification both run entirely in your browser using the native Web Crypto API — your token, secret and keys never leave your device and are not logged or stored. Because it is a client-side tool with no server round-trip, it works offline once loaded. Still, as a matter of good practice, never paste a production signing secret into any website.
Method, standards & references
Method: the token is split into three base64url parts (RFC 7519); the header and payload are decoded to JSON in the browser; the signature is verified with the native Web Crypto API — HMAC-SHA256 for HS256, RSASSA-PKCS1-v1.5 for RS256, ECDSA/P-256 for ES256. The verifier rejects alg: none and refuses to verify an asymmetric token with a symmetric secret. Nothing is sent to a server. Not a substitute for server-side validation.
How we calculate this
Reviewed by Reckonist Editorial · Last reviewed 4 July 2026. Figures follow the methods and sources set out in our editorial standards.
This tool decodes and verifies JSON Web Tokens locally in your browser for inspection and debugging. It is not a substitute for server-side token validation, and reading a token proves nothing about its authenticity. Never paste production signing secrets into any website.
Read more on this
Keep going
Same-category tools follow this colour; a cross-category link keeps its own.