Introduction
JSON Web Tokens (JWTs) are the standard for stateless authentication in modern web applications. When you debug an API response, inspect a token payload, or learn how OAuth 2.0 works, you need to see what is inside a JWT without sending it to a third-party server. This tool decodes the header and payload of any JWT in your browser. It also verifies HMAC (HS256/HS384/HS512) and RSA (RS256/RS384/RS512) signatures locally using the Web Crypto API, so you can confirm token authenticity without exposing your secret key. Paste a token below to start.
What this tool does
- Decodes JWT header and payload segments from Base64url encoding into formatted JSON.
- Verifies HS256, HS384, and HS512 signatures using the Web Crypto API and a shared secret you provide.
- Verifies RS256, RS384, and RS512 signatures using a PEM-encoded public key you provide.
- Detects the signing algorithm from the token header and displays it alongside the decoded content.
- Processes everything client-side. Your tokens and secret keys never leave your browser.
How this tool works
The decoder splits the JWT at its period boundaries, Base64url-decodes the header and payload, and parses the JSON. The signature segment is preserved for display. When you toggle "Verify signature" and enter a secret or public key, the tool uses `crypto.subtle.importKey` and `crypto.subtle.verify` from the Web Crypto API to recompute the HMAC or RSA signature over the `header.payload` string and compare it to the token's signature. The algorithm is read from the JWT header (`alg` claim), so the tool automatically selects the correct verification method. All operations run locally in your browser with no network requests.
How JSON Web Tokens work
A JSON Web Token (JWT), defined in RFC 7519, consists of three Base64url-encoded segments concatenated with periods:
`HEADER.PAYLOAD.SIGNATURE`
Base64url vs standard Base64: Base64url makes two substitutions so tokens can appear in URLs and HTTP header values without percent-encoding. Standard Base64 uses `+` (62) and `/` (63) and pads with `=`. Base64url replaces them with `-` (62) and `_` (63) and omits padding entirely. Decoding a JWT requires restoring the `-` to `+` and `_` to `/` substitutions and adding back the padding before calling `atob()`.
The three sections: - Header: A JSON object specifying the signing algorithm (`alg`) and token type (`typ`). Example: `{"alg":"HS256","typ":"JWT"}`. - Payload: A JSON object of *claims*. RFC 7519 registers seven standard claim names: - `iss` (Issuer) — who created the token - `sub` (Subject) — who the token represents - `aud` (Audience) — who should accept the token - `exp` (Expiration Time) — Unix timestamp after which the token is invalid - `nbf` (Not Before) — Unix timestamp before which the token must not be accepted - `iat` (Issued At) — Unix timestamp when the token was created - `jti` (JWT ID) — a unique identifier for this token (prevents replay) - Signature: HMAC or RSA signature bytes over `HEADER.PAYLOAD`, encoded in Base64url. Only parties who hold the secret key (HMAC) or the private key (RS256) can produce a valid signature.
Signature verification with the Web Crypto API: For HS256 tokens, the tool calls `crypto.subtle.importKey` with the raw bytes of your secret string and the algorithm parameters `{ name: "HMAC", hash: "SHA-256" }`. It then calls `crypto.subtle.verify("HMAC", key, signatureBytes, signingInput)`, which returns a boolean. For RS256, the tool imports your PEM public key in SPKI format using `{ name: "RSASSA-PKCS1-v1_5", hash: "SHA-256" }` and verifies the RSA signature the same way. The Web Crypto API is available natively in all modern browsers and in Node.js 18+.
Critical implication: The header and payload are encoded, not encrypted. Anyone who possesses a JWT can decode and read both sections without the secret key. Never put passwords, PII, or sensitive business logic in JWT claims unless the token uses JWE (JSON Web Encryption, RFC 7516) rather than JWS (JSON Web Signature).
How to use this tool
- Copy the complete JWT from your browser's developer tools, API response, or Authorization header.
- Paste the token into the input field. The decoder processes it instantly and shows formatted JSON.
- Review the decoded header and payload. Check the exp, iat, iss, and aud claims for debugging.
- To verify the signature, toggle 'Verify signature' and enter the HMAC secret or paste the PEM public key.
- The tool displays VALID or INVALID based on whether the recomputed signature matches the token's signature.
Real-world examples
Debugging expired sessions
A developer notices users getting logged out after one hour. She copies a JWT from the browser's Network tab, pastes it here, and sees the `exp` claim is set to 3600 seconds after `iat` instead of the intended 86400. She updates the server configuration, generates a new token, and uses the decoder to confirm the new expiration. She then toggles signature verification with the shared secret to confirm the new token was signed correctly.
Verifying a third-party API token
A backend developer integrates with a payment API that signs JWTs with RS256. The API provider publishes their public key in PEM format. The developer pastes a token here, toggles verification, pastes the public key, and confirms the signature is VALID. This proves the token was issued by the provider and has not been tampered with, without the developer needing to install a JWT library or write a verification script.
Learning token structure
A computer science student studying OAuth 2.0 generates sample tokens from Google, Auth0, and Firebase, then decodes each one here. Comparing the claim structures side by side reveals how different providers encode scope, role, and email verification status. The student notices that all three use HS256 or RS256 but structure their custom claims differently, which informs the design of their own authentication system.
Comparison with similar methods
| Method | Complexity | Typical use |
|---|---|---|
| Decode only (no key needed) | Low | Inspecting header and payload contents for debugging |
| Decode + verify HS256/HS384/HS512 | Medium | Confirming HMAC-signed token authenticity with a shared secret |
| Decode + verify RS256/RS384/RS512 | Medium | Confirming RSA-signed token authenticity with a public key |
Limitations or considerations
Decoding a JWT reveals its contents to anyone who has the token, because the header and payload are Base64url-encoded, not encrypted. Signature verification confirms that the token was signed by a party holding the secret or private key, but it does not encrypt the payload. This tool does not support ES256 (ECDSA) verification yet. Very large tokens or tokens with unusually large payloads may slow down the JSON formatting, though most real-world JWTs are under 8 KB. If verification fails, check that you are using the correct algorithm type (HMAC secret vs RSA public key) for the token's `alg` header claim.
Frequently asked questions
Is it safe to decode and verify JWTs in this tool?
Yes. All decoding and verification happens in your browser using the Web Crypto API. Your tokens and secret keys are never sent to a server. Avoid server-based JWT tools that might log your tokens.
What JWT algorithms can this tool verify?
HS256, HS384, and HS512 (HMAC with a shared secret) and RS256, RS384, and RS512 (RSA with a public key). The tool reads the alg claim from the token header and applies the correct verification method automatically.
What do common JWT claims mean?
exp (expiration time), iat (issued at), iss (issuer), aud (audience), sub (subject), nbf (not before), and jti (JWT ID) are the seven registered claims defined in RFC 7519.
Can I decode tokens from any OAuth provider?
Yes. JWT is a universal standard (RFC 7519). Tokens from Google, Auth0, Firebase, AWS Cognito, and custom implementations all decode the same way. For verification, you need the correct secret (HS256) or public key (RS256) from the provider.
Why does verification fail even though the token is valid?
The most common cause is using an HMAC secret with an RS256 token, or a public key with an HS256 token. Check the alg field in the decoded header. Other causes include trailing whitespace in the secret, or a PEM key with incorrect formatting.
Conclusion
Use this tool to decode any JWT and verify HS256 or RS256 signatures without installing a library or sending your token to a server. It is built for debugging authentication flows, confirming token authenticity during development, and learning how JWT structure works. For related tools, try the Base64 Encode/Decode page to understand the encoding layer, or the HMAC Generator to compute HMAC signatures manually.