JWT Decoder & Verifier
Decode, build, and verify JWT tokens — entirely client-side (HS256).
Why use this tool
01Free JWT decoder, builder, and HS256 signature verifier. Inspect header and payload claims, sign new tokens, and validate signatures locally — no token or secret ever leaves your browser.
Decode, build, and verify JWTs in one place: paste a token to inspect its header and payload, generate a signed HS256 token from a JSON payload, or verify any token's signature against a shared secret.
Decoding and verifying are different operations — decoding only Base64url-decodes the parts (useful for inspection, never proves authenticity), while verifying recomputes the HMAC signature with your secret. Most security incidents come from confusing the two; this tool keeps them in separate tabs so you cannot mix them up.
Everything runs locally using the browser's Web Crypto API. Tokens from production systems, internal secrets, and unreleased payloads are safe to paste — nothing is uploaded, logged, or analyzed.
How to use
02Quick checks before you copy
03Confirm the input is the format you intended.
Scan the result before using it in a document, URL, config, or message.
Copy only the output you need.
Use Cases
Paste a JWT from your app's local storage or authorization header to inspect the user ID, roles, and expiry without writing code.
When a user reports they can't access a resource, decode their JWT to check if their role claim or expiry is the cause.
Confirm that your auth server is issuing tokens with the correct claims before writing application code that depends on them.
Decode a JWT's payload to read the exp (expiry) timestamp and verify whether a token is still valid.
Tips & Tricks
- 01JWTs are not encrypted — treat them as public
A JWT payload is only Base64url-encoded, not encrypted. Anyone who has the token can decode and read its claims. Never put sensitive data in the payload.
- 02The exp claim is a Unix timestamp
The exp field contains seconds since Jan 1 1970 UTC. Use the Timestamp Converter tool to convert it to a human-readable date.
- 03Decoding is not verification
Decoding only Base64url-decodes the header and payload — it tells you nothing about whether the token is authentic. To prove a token was issued by your auth server, run signature verification on the Verify tab with the shared secret (for HS256) or have your server check it with the public key (for RS256/ES256).
- 04Three parts separated by dots
A JWT looks like xxxxx.yyyyy.zzzzz. The first part is the header (algorithm), the second is the payload (claims), the third is the signature.
- 05Beware of the alg: none attack
If a server accepts tokens with header alg: none, anyone can forge a token by setting alg: none and omitting the signature. Your server should reject the none algorithm explicitly — never decide trust based on the header's alg value alone.
FAQ
04What is the difference between decoding and verifying a JWT?
Decoding only Base64url-decodes the header and payload — it works on any well-formed token, including forged or tampered ones. Verifying recomputes the HMAC (HS256) or signature check using a secret or public key and confirms the token was actually issued by your auth server. Use the Decode tab for inspection; use the Verify tab to prove authenticity.
Can this tool verify the JWT signature?
Yes — open the Verify tab, paste the token, and provide the shared HS256 secret. The tool recomputes the HMAC-SHA256 signature in your browser using the Web Crypto API and returns valid or invalid. For RS256 or ES256 (asymmetric algorithms), verification must happen on the server with the corresponding public key.
Is my JWT or secret sent to a server?
No. Decoding, signing, and verification all happen locally via the Web Crypto API. Tokens and secrets never leave your browser — no upload, no logging, no analytics on the content.
Why does my decoded payload show numbers instead of dates?
JWT timestamps (iat, exp, nbf) are Unix timestamps — seconds since January 1, 1970 UTC. The decoder surfaces the parsed expiry above the JSON, and you can paste the raw number into the Timestamp Converter tool to read other claims.
What is the alg: none vulnerability?
Some JWT libraries trust the header's alg field to decide which algorithm to verify with. If your server accepts alg: none, an attacker can submit a forged token with no signature and have it accepted. Always pin the expected algorithm on the server side and reject none explicitly.
What's the difference between the header and payload?
The header contains the token type and signing algorithm (alg, typ). The payload contains the claims — standard fields like iss (issuer), sub (subject), aud (audience), exp (expiry), iat (issued at), nbf (not before), plus any custom data your app embeds.
Can I decode a JWT that's been modified?
Yes — any valid Base64url string decodes. That's exactly why decoding alone proves nothing. The signature is what binds the header and payload to the issuer; any change to either invalidates the signature on verify.
Should I use HS256 or RS256?
Use HS256 when the issuer and verifier share one trusted secret (single backend). Use RS256 (or ES256) when verifiers should not be able to issue tokens — the private key signs, the public key verifies. This tool covers HS256 fully; RS256 tokens decode but verification needs server-side public-key checks.
Related tools
03JSON Formatter→
Format, minify, and validate JSON in one place.
Base64 Encoder / Decoder→
Encode text to Base64 or decode Base64 to text.
Hash & HMAC Generator→
Generate SHA-1/256/384/512 and MD5 hashes plus keyed HMAC codes.