JWT Decoder & Signer
Decode header and payload, check expiry, and sign HS256/384/512 tokens — all in your browser.
Runs entirely in your browser — nothing you paste is uploaded.
About JWT Decoder & Signer
A JWT is three base64url segments separated by dots: a header naming the algorithm, a payload of claims, and a signature over the first two. Decoding is trivial and requires no key — which is the first thing to understand about the format. Anyone holding your token can read every claim in it.
The decoder shows the header and payload as formatted JSON and turns the time claims into something readable: `iat` (issued at), `nbf` (not before) and `exp` (expiry) as real dates with a relative offset, plus a clear verdict on whether the token has expired. Debugging an auth failure usually ends at that line.
The signer goes the other way. Edit a header and payload, supply a secret, and get a signed HS256, HS384 or HS512 token using the Web Crypto API — with helpers for setting `iat` and `exp` relative to now. There's a generate-secret button that produces 32 random bytes as base64url, which is the right length for HS256 and the thing most people are actually looking for when they search for it.
Nothing leaves the tab: no token, no secret, no payload. The secret is never written into the URL or into `history.replaceState`, so it can't end up in a browser history, a screenshot of the address bar, or a referrer header.
Frequently asked
›Is it safe to paste a JWT into an online decoder?
Into this one, yes — the decode happens in your browser and no request is made. Into a hosted one, treat the token as compromised. A JWT is a bearer credential: whoever holds it can act as you until it expires.
›Can I decode a JWT without the secret?
Yes. The payload is base64url-encoded, not encrypted. The secret only verifies that the token hasn't been altered — it does not hide anything. Never put something in a JWT payload that the token's holder shouldn't see.
›What is the `alg: none` attack?
An attacker rewrites the header to `{"alg":"none"}`, strips the signature, and a naive verifier that trusts the header's algorithm accepts it. The fix is on the verifying side: pin the expected algorithm in your verification call rather than reading it from the token.
›How long should an HS256 secret be?
At least 256 bits — 32 random bytes — because HMAC-SHA256's security is capped by its key length. A memorable passphrase is not a key; it's brute-forceable offline against any token you've ever issued. Use the generate button.
›HS256 or RS256?
HS256 is symmetric: the same secret signs and verifies, so every verifier can also mint tokens. RS256 is asymmetric — sign with a private key, distribute the public key — which is what you want when tokens cross a service boundary. This tool signs HMAC algorithms only.