JWT Decoder & Encoder
Read a JWT apart into header, payload and signature, check its claims, verify an HMAC signature or sign a new token — entirely in your browser
Decode reads a token apart. Encode signs a new one.
Verify signature
Your token and secret never leave your browser — nothing is sent to a server.
Signature Verification
Check HS256, HS384 and HS512 against your secret
Claim Inspection
exp, nbf and iat rendered as dates with time remaining
Nothing Leaves the Page
Decoding and signing run in your browser, not a server
Frequently asked questions
Is it safe to paste a token here?
Safer than most JWT sites, because this page has no server to send it to: the decoding is plain string work and the signing uses your browser's built-in WebCrypto. Your token and secret never leave the tab, and nothing is stored. That said, a token you paste anywhere is a token that has been on your clipboard — if it is a live production credential, revoke or rotate it rather than trusting any tool, including this one.
What are the three parts of a JWT?
A JWT is three base64url-encoded chunks joined by dots. The header says which algorithm signed the token and what type it is. The payload holds the claims — who the token is about, who issued it, when it expires, plus whatever the application added. The signature is a MAC or digital signature over the first two parts, and it is the only thing stopping someone from editing the payload. Note that the header and payload are encoded, not encrypted: anyone holding the token can read them, so never put a secret in a JWT payload.
Why does my token show "Unsecured"?
Its header says `alg: "none"` and it carries no signature, which the JWT spec calls an unsecured token. Anyone can edit the payload of such a token and it will still parse. Historically several libraries accepted `none` by default, which let attackers strip the signature off a real token and have it accepted — so a verifier should always pin the algorithms it will accept rather than trusting the header.
Why can't this verify an RS256 token?
RS256, ES256 and the other asymmetric algorithms are verified with the issuer's public key, usually fetched from a JWKS endpoint. That would mean asking you to paste a key or letting this page make network requests, which is at odds with the tool running entirely offline — so it is not offered. The header, payload and claims of an RS256 token still decode normally here; only the signature check is skipped.
What do exp, iat and nbf mean?
They are the registered time claims, and all three are Unix timestamps in seconds — not milliseconds, which is the most common bug when tokens are minted by hand. `iat` is when the token was issued, `exp` is when it stops being valid, and `nbf` ("not before") is when it starts being valid, which lets you issue a token ahead of time. The claims table here shows each as a readable date plus how long ago or how far ahead it is.