JWT Decoder: Decode, Verify and Encode JSON Web Tokens
Paste a token to see the header, payload and claims in plain words, check if it has expired and verify the signature. The token, secret and keys never leave your device.
The token, secret and keys are processed only on this page: not sent anywhere, not added to the URL or analytics.
header · payload · signature
Verify signature
Algorithm:—This is the only network request on the page, and it is sent only when you press the button.
Checks
Header
Payload
Claims
The encoder signs with HMAC (HS256, HS384, HS512). It is meant for test tokens: never use it with production secrets on a shared computer.
Signed token
Building APIs with token-based auth?
We design and build APIs, OAuth 2.0 and OpenID Connect flows, and test them for vulnerabilities. Tell us about your project and get an estimate.
Thank you! We will reply within one business day.
TL;DR: paste a JSON Web Token above and the decoder shows its header and payload as formatted JSON, explains the standard claims, tells you whether the token has expired and verifies the signature with your secret or public key. The Encoder tab builds HS256, HS384 and HS512 tokens for tests. Everything happens in your browser.
We built this JWT decoder for our own work on APIs and authentication at YuSMP Group. If you need a team to design token-based auth or to check it for vulnerabilities, see our API development services and penetration testing and security audits.
What is a JWT?
A JSON Web Token (RFC 7519) is a compact string of three Base64URL parts separated by dots: header.payload.signature. The header names the signing algorithm (alg) and sometimes the key id (kid). The payload holds claims: who issued the token, who it is for and when it expires. The signature proves that nobody changed the first two parts. The payload is encoded, not encrypted: anyone who has the token can read it.
How to decode and verify a JWT
- Paste the token into the “Encoded token” field. A
Bearerprefix and line breaks are removed automatically. The three parts are coloured: header, payload, signature. - Read the result. Header and payload appear as formatted JSON. The Claims block turns
exp,iatandnbfinto dates in UTC and your time zone and shows “expired 10 minutes ago” or “expires in 3 hours”. - Check the warnings. The tool flags
alg: none, expired or not yet valid tokens, a missingexp, timestamps in milliseconds and payload fields that look like personal data. - Verify the signature. For HS256/384/512 enter the shared secret as text or Base64. For RS, PS, ES and EdDSA paste the public key as PEM, an X.509 certificate, a JWK or a whole JWKS, or load the JWKS by URL: the right key is picked by
kid.
Which algorithms are supported?
- HMAC — HS256, HS384, HS512: shared secret (text or Base64).
- RSA — RS256, RS384, RS512, PS256, PS384, PS512: RSA public key: PEM, PKCS#1, certificate, JWK.
- ECDSA — ES256, ES384, ES512: EC public key P-256, P-384 or P-521.
- EdDSA — Ed25519: Ed25519 public key, if your browser supports it.
Verification uses the WebCrypto API built into the browser. We checked it against the examples from RFC 7515 and against tokens from jwt.io and Python cryptography for every algorithm in the table.
Common JWT mistakes
- Trusting the payload without checking the signature. Decoding is not validation: the server must verify the signature,
exp,issandaudon every request. - Accepting
alg: noneor letting the token choose the algorithm. Pin the expected algorithm on the server. - A short HS secret. RFC 7518 requires a key at least as long as the hash: 32 bytes for HS256, 64 for HS512. Short secrets can be brute-forced offline.
- Personal data in the payload. Email, phone or address in a JWT is readable by anyone who sees the token, including browser extensions and logs.
- Milliseconds in
exp. JWT times are in seconds. A value like1735689600000means the year 56,971, so the token never expires.
FAQ
Is it safe to paste a production token here?
The decoder works entirely in your browser: the token, secret and keys are not sent to a server, not added to the URL and not passed to analytics. Nothing is saved unless you tick “Remember”. Still, treat live tokens as passwords and prefer expired or test ones when you can.
What is the difference between decoding and verifying a JWT?
Decoding only reads the Base64URL parts and shows the JSON. Verifying recalculates the signature with the secret or public key and proves that the header and payload were not changed. A token can decode fine and still have an invalid signature.
Why does it say “Invalid signature” when the token works in my app?
Most often the secret is in a different encoding: try switching between Text and Base64. For RS and ES tokens make sure the public key matches the kid in the header. For HS256, HS384 and HS512 the secret must be the same bytes the server uses, including line breaks.
Can I verify a token with a JWKS URL?
Yes. Paste the URL of the JWKS (for example /.well-known/jwks.json) and press “Load keys”. This is the only request the page makes, and only on that button. If the server does not allow browser requests (CORS), open the URL yourself and paste the JSON into the key field.
Can I create a JWT with this tool?
Yes, on the Encoder tab. Edit the header and payload JSON, choose HS256, HS384 or HS512 and enter a secret. Buttons set iat to now and exp to one hour ahead. The signed token can be copied or opened in the decoder.
Does it support encrypted tokens (JWE)?
No. A JWE has five parts and its payload is encrypted, so it cannot be read without the private key. The decoder recognises such tokens and tells you so.