JWT Decoder & Verifier
🔒 Runs in your browser
Signature verification
The header algorithm is not HS256 or RS256 — verification is unavailable for this token type.
Decoding is not decryption
A JWT (JSON Web Token) is signed, not encrypted: its header and
payload segments are only base64url-encoded JSON, readable by anyone who has
the token — that is by design, not a flaw. The signature only proves who issued the token;
it never hides what is inside it, so a JWT should never carry secrets.
The token never leaves your browser
Decoding, claim inspection and signature verification — HS256 with a shared secret, RS256 with an SPKI public key — all run locally using the native Web Crypto API. The token, the secret and the key you paste in are never sent to a server: nothing about this tool works by uploading your data, which matters because JWTs frequently carry session or user identity claims.
Frequently asked questions
Is decoding a JWT the same as decrypting it?
No — a standard JWT (JWS) is signed, not encrypted. Its header and payload are only base64url-encoded JSON, readable by anyone who has the token, by design. The signature only proves who issued it — it does not hide the payload's contents.
Is my token sent to a server to verify the signature?
No. Both decoding and signature verification (HS256 with a shared secret, RS256 with a public key) run entirely in your browser using the Web Crypto API — the token never leaves your browser.
What do exp, iat and nbf mean?
exp (expiration time) is the moment after which the token must be rejected; iat (issued at) records when it was created; nbf (not before) marks the earliest moment it becomes valid. All three are Unix timestamps in seconds, shown here as readable dates.
Why does verification ask for a secret or a PEM key?
The check depends on the algorithm in the token's header: HS256 needs the same shared secret used to sign it, while RS256 needs the issuer's SPKI public key (PEM) — never a private key, which should never be pasted into any tool, including this one.