Cryptography Tools
What It Does
Decodes and optionally verifies JSON Web Tokens. Decoding reveals the header and payload without needing a key. Verification confirms the signature is valid and the claims (expiration, audience, etc.) are satisfied.
How to Use It
- Paste a JWT into the input field. The token is decoded instantly — you can see the header and payload without any key.
- Review the decoded sections. The header shows the algorithm (
alg) and token type. The payload shows all claims with human-readable timestamps. - To verify the signature, switch to “Verify” mode, enter the secret or public key, and click “Verify Signature”.
- Check claim validation results that appear below: expiration status, not-before check, audience match, and issuer match.
Decode vs. Verify — What’s the Difference?
| Mode | Needs Key? | What It Checks |
|---|---|---|
| Decode | No | Reads the header and payload. Useful for inspecting a token’s contents, but proves nothing about authenticity. |
| Verify | Yes | Validates the cryptographic signature, then checks time-based claims (exp, nbf) and optionally validates aud and iss. |
Options Explained
| Option | Description |
|---|---|
| Mode | Decode (no key needed) or Verify (requires the signing key). |
| Key encoding | How the verification key is provided: UTF-8 (plain text secret for HMAC), Hex, Base64, PEM (for RSA/EC public keys), or JWK (JSON Web Key format). |
| Leeway | Seconds of clock-skew tolerance for exp and nbf checks. Set this if your server clocks may differ slightly (common values: 30–60 seconds). |
| Expected Audience | If provided, the aud claim in the token must match this value, otherwise verification fails. |
| Expected Issuer | If provided, the iss claim must match, otherwise verification fails. |
Understanding Claim Validation
| Claim | Validation |
|---|---|
exp (Expiration) | Token is rejected if the current time is past this timestamp (plus leeway). A “Token expired” message appears with how long ago it expired. |
nbf (Not Before) | Token is rejected if the current time is before this timestamp (minus leeway). Useful for tokens that should activate in the future. |
aud (Audience) | If you supply an expected audience, the decoder checks that the token’s aud matches. A mismatch means the token was intended for a different service. |
iss (Issuer) | If you supply an expected issuer, the decoder checks that the token’s iss matches. A mismatch means the token came from an untrusted source. |
Providing the Right Key
- HMAC tokens (HS256/384/512): Enter the same shared secret used to sign the token. Use the matching encoding (UTF-8, Hex, or Base64).
- RSA tokens (RS256/384/512): Paste the public key in PEM format (starts with
-----BEGIN PUBLIC KEY-----). - ECDSA tokens (ES256/384/512): Paste the EC public key in PEM format.
- JWK format: Paste the JSON Web Key object directly. Useful when your identity provider publishes a JWKS endpoint.
In the token textbox below, the header, payload, and signature parts of the JSON Web Token are color-coded for visual users, but all three parts can be edited as normal text.
Header
Payload
About JWT Decoding
Decoding a JSON Web Token (JWT) means splitting the token at its two dot separators and Base64URL-decoding each segment to reveal the header and payload as readable JSON. Because JWTs are only encoded — not encrypted — anyone with access to the token can inspect its contents. This makes decoding an essential first step for debugging authentication flows, verifying claim values, and checking expiration timestamps.
Verification goes one step further: it re-computes the signature using the provided key and compares it to the signature in the token. A valid signature proves the token has not been tampered with since it was issued. For HMAC tokens you supply the same shared secret used during signing; for RSA or ECDSA tokens you supply the corresponding public key. The tool also checks standard claims such as exp (expiration), nbf(“not before”), iss (issuer), andaud (audience) to confirm the token is still valid and intended for the expected recipient.
Never rely solely on decoding without verification in production systems. An unverified token could have been forged or altered by an attacker. Always verify the signature and validate the claims before trusting the token's content.
Common Use Cases
- Inspecting tokens during development to confirm claims (roles, scopes, expiration) are set correctly
- Verifying the signature of tokens received from third-party identity providers such as OAuth 2.0 and OpenID Connect
- Debugging “401 Unauthorized” errors by checking whether a token has expired or targets the wrong audience
- Validating tokens in API gateways and microservice meshes before forwarding requests
- Auditing token payloads to ensure no sensitive data is inadvertently exposed
What Is JWT Decoding?
JWT decoding is the process of splitting a JSON Web Token into its three components — header, payload, and signature — and Base64URL-decoding each part to reveal the underlying JSON data. Decoding alone does not verify the token; signature verification is a separate step that confirms the token was issued by a trusted party and has not been altered. Inspecting a JWT lets you examine claims such as sub (subject), exp(expiration), iat (issued at), and custom claims like roles and permissions — which is essential for debugging authentication flows and auditing token contents.
Frequently Asked Questions
Does decoding a JWT verify its signature?
No. Decoding only reveals the header and payload. To confirm the token is authentic and unmodified, you must also verify the signature using the correct key or secret.
What does a “Token expired” error mean?
It means the current time is past the exp(expiration) claim in the payload. The issuing server should provide a new token via a refresh token flow.
Can I decode JWTs from any identity provider?
Yes. The JWT format is standardized (RFC 7519), so tokens from Auth0, Firebase, Okta, Azure AD, or any compliant provider can be decoded and inspected here.
Is my token sent to a server?
No. All decoding and verification runs locally in your browser. Your token and keys are never transmitted or stored.
All decoding and verification runs entirely in your browser. No tokens or keys are sent to any server, ensuring your credentials remain private.