# JWT Decoder & Verifier > Decode a JSON Web Token's header and claims, read its expiry and timing in plain language, and verify an HS256/384/512 signature with a pasted secret. Runs entirely in your browser. - Tool: https://ronutz.com/en/tools/jwt - Family: Identity & tokens --- ## What it does Paste a JSON Web Token to read what is inside it and, for an HMAC-signed token, to check that its signature is valid. The tool splits the token into its three parts, decodes the header and the claims, translates the timing claims into plain dates, and, if you supply the secret, verifies an HS256, HS384, or HS512 signature. Everything runs in your browser; a pasted secret never leaves it. ## The shape of a JWT A JWT in its usual compact form is three Base64url segments joined by dots: `header.payload.signature`. The **header** names the signing algorithm (`alg`) and often a key id (`kid`); the **payload** carries the claims, a JSON object of statements about the subject; and the **signature** is computed over the first two segments so that any tampering with them can be detected. The registered claims include the issuer (`iss`), subject (`sub`), audience (`aud`), and the timing fields `iat`, `nbf`, and `exp`, which are numeric seconds since the Unix epoch and which the tool renders as readable dates. ## Decoding is not verifying This is the single most important thing to understand about a JWT: the header and payload are only Base64url-encoded, not encrypted. Anyone who has the token can read them, so a JWT is not a place to put secrets. Decoding tells you what a token claims; it does not tell you whether those claims are true. Only verifying the signature against the right key proves the token was issued by who it says and has not been altered. ## Signature verification and the algorithm HS256, HS384, and HS512 sign with an HMAC over a shared secret, the same construction the HMAC tool uses, so this verifier and that tool agree. Because the secret both signs and verifies, anyone who can verify an HS-signed token can also mint one; that is the symmetric trade-off, and it is why services that must let others verify without being able to forge use an asymmetric algorithm like RS256 or ES256 instead. A known family of attacks abuses the `alg` field, either setting it to `none` or tricking a server that holds an RSA public key into treating it as an HMAC secret; the best-current-practice guidance in RFC 8725 exists to close these, and the short version is to always check that the algorithm is the one you expect. ## Using it Paste a token to decode its header and claims and read its timing in plain language. To verify an HMAC-signed token, paste the shared secret and the tool confirms whether the signature matches. Whether a token is expired right now is shown against your current clock, layered on top of the timing claims the decoder reads. ## Standards and references - [RFC 7519 - JSON Web Token (JWT)](https://www.rfc-editor.org/rfc/rfc7519) - claims set + registered claim names - [RFC 7515 - JSON Web Signature (JWS)](https://www.rfc-editor.org/rfc/rfc7515) - compact serialization + signing input - [RFC 7518 - JSON Web Algorithms (JWA)](https://www.rfc-editor.org/rfc/rfc7518) - alg values (HS256, RS256, ES256, none) - [RFC 8725 - JWT Best Current Practices](https://www.rfc-editor.org/rfc/rfc8725) - alg confusion + validation guidance ## Related reading - [Access tokens, refresh tokens, and ID tokens](https://ronutz.com/en/learn/oauth-tokens.md): Three OAuth and OpenID Connect tokens that get constantly confused, what each is actually for, and why sending the wrong one to the wrong place is a real bug. - [Anatomy of a JSON Web Token](https://ronutz.com/en/learn/jwt-anatomy.md): The three segments of a JWT, how the signature makes it trustworthy, and why decoding a token is not the same as verifying it. - [JWT security pitfalls: alg:none, key confusion, and missing checks](https://ronutz.com/en/learn/jwt-security.md): The handful of mistakes that turn a JWT verifier into a forgery machine, and the validation a correct verifier must perform. - [JWT signing algorithms: HMAC, RSA, and ECDSA](https://ronutz.com/en/learn/jwt-signing-algorithms.md): Why a JWT's alg header matters, the difference between symmetric and asymmetric signing, and how to choose. - [OIDC vs OAuth 2.0: Authentication vs Authorization](https://ronutz.com/en/learn/oidc-vs-oauth.md): Why OAuth 2.0 is about authorization and OpenID Connect is about authentication, the difference between an access token and an ID token, why using plain OAuth as a login mechanism is a known antipattern, and how to tell which token is which. - [OpenID Connect: An Identity Layer on OAuth 2.0](https://ronutz.com/en/learn/oidc-overview.md): What OpenID Connect adds to OAuth 2.0, the ID token at the center of it, the relying party and provider roles, how the authorization code flow delivers an ID token, and why an ID token is just a JWT you can decode and read. - [OpenID Connect: identity on top of OAuth 2.0](https://ronutz.com/en/learn/openid-connect.md): How OIDC adds authentication to OAuth's authorization, what the ID token is, and why the code flow with PKCE is the recommended path. - [The ID Token Claims, and What a Relying Party Checks](https://ronutz.com/en/learn/id-token-claims.md): The claims inside an OIDC ID token: the required iss, sub, aud, exp, and iat; the nonce that stops replay; azp when there are multiple audiences; acr and amr for authentication strength; auth_time; and the at_hash and c_hash binding claims, with the validation a relying party performs on each. - [The OAuth 2.0 authorization code flow](https://ronutz.com/en/learn/oauth-code-flow.md): The four roles, the redirect-and-exchange dance, and why the code is swapped for a token on the back channel.