JWT Decoder & Verifier

A JSON Web Token (JWT) is a compact, URL-safe way to carry a set of claims - facts about a user or client - between two parties. It is the format behind most modern authentication: after you log in, the server hands your browser or app a signed JWT, and every following request presents that token so the API knows who you are without a database lookup.

A JWT is three Base64URL strings joined by dots: header.payload.signature. The first two are just JSON that anyone can read - this tool decodes them instantly. The third is a cryptographic signature that proves the token has not been tampered with.

• Header - JSON describing how the token is signed. The key field is alg (the algorithm, e.g. HS256 or RS256); kid names which key to use.
• Payload - JSON holding the claims: registered ones like sub, exp, and iss, plus any custom fields your app adds (roles, scopes, tenant IDs).
• Signature - the header and payload run through the signing algorithm with a key. Change a single byte of the header or payload and the signature no longer matches.

Because the header and payload are only encoded, not encrypted, decoding a JWT never needs a key or password. Verifying it does.

The signature is computed over the exact string base64url(header) + "." + base64url(payload). To verify a token you recompute or check that signature and confirm it matches - which also proves the token was issued by whoever holds the key and has not been altered.

How you check it depends on the algorithm family:

• HMAC (HS256/384/512) uses one shared secret for both signing and verifying. Paste that secret to verify.
• RSA and ECDSA (RS/PS/ES) use a key pair: the issuer signs with a private key, and you verify with the matching public key (or a JWK / certificate). You never need the private key to verify.

This tool performs the check with the browser's native Web Crypto API, so your secret or key never leaves the page.

This is the most important and most misunderstood point: a standard JWT provides integrity, not confidentiality. The payload is Base64URL, which anyone who intercepts the token can decode in one step - exactly what this tool does. The signature stops them from changing it, but it does nothing to hide it.

So never put secrets in a payload: no passwords, no card numbers, no private personal data. If the contents truly must be hidden, you need an encrypted token (JWE), which is a different format. For an ordinary signed JWT, treat the payload as public.

The two most common algorithms answer one question differently: who is allowed to create tokens?

Use HS256 when the same service both issues and checks the token. Use RS256 (or ES256) when tokens are issued centrally and verified elsewhere, so verifiers only ever hold the public key and can never mint their own tokens.

• Accepting alg: none- a token can declare it is unsigned. A verifier that trusts the header's alg blindly will accept a forged, unsigned token. Always pin the expected algorithm on the server.
• The algorithm-confusion attack - if a server verifies with a public key but does not pin the algorithm, an attacker can re-sign a token as HS256 using that public key as the HMAC secret. Pin the alg.
• Not checking exp - decoding a token is not validating it. A correct server must reject expired tokens and check nbf, aud, and iss too.
• Trusting a decoded payload - reading claims without verifying the signature means trusting data anyone could have edited. Verify first, then trust.