JWT Decoder

Paste a JWT to decode its header, payload and signature. Claims are extracted and readable dates shown for timestamps. Verify HS256, HS384 and HS512 signatures with your secret.

jwt-decoder.tool

What a JWT Actually Contains

Every JWT is three Base64URL-encoded strings joined by dots. The header declares the algorithm and token type. The payload carries the claims — the actual data, including standard fields like expiry time, issuer, and subject, plus any custom data your application adds. The signature is a cryptographic hash of the header and payload, which allows the receiver to verify the token was not tampered with.

Decoding is not the same as verifying. Anyone can decode a JWT without any key — the payload is just Base64URL encoding, not encryption. Verification requires the secret or public key to confirm the signature is valid. Use the Signature Verification panel to check HS256, HS384 and HS512 signatures.

Standard Claims

  • exp — expiration time. Unix timestamp after which the token must not be accepted.
  • iat — issued at. When the token was created.
  • nbf — not before. The token must not be accepted before this time.
  • iss — issuer. Identifies who issued the token (e.g. your auth server URL).
  • sub — subject. Usually the user ID the token is issued for.
  • aud — audience. The intended recipients of the token.
  • jti — JWT ID. A unique identifier for this specific token, used to prevent replay attacks.

Signature Verification

The verification panel supports HMAC-based algorithms — HS256, HS384 and HS512. Enter the secret that was used to sign the token and click Verify. The algorithm is read automatically from the token header. If the token was signed with an asymmetric algorithm (RS256, ES256, etc.) signature verification requires the public key, which is beyond the scope of a browser tool.

Frequently Asked Questions

Decoding runs entirely in your browser — no data is sent to any server. However, you should still treat JWTs as sensitive credentials. Never paste a live production token with real user data into any online tool if you can avoid it. For testing and debugging, use tokens from a development environment or generate a sample token with dummy data.
The payload is encoded with Base64URL, not encrypted. Base64URL is a reversible encoding — anyone who can see the token can read its contents. This is by design: JWTs are meant to be readable so the receiving party can use the claims. Security comes from the signature, which proves the token was issued by a trusted authority and has not been modified. If your payload contains sensitive data, consider encrypting it using JWE (JSON Web Encryption) instead of standard JWT.
Either the secret is wrong, or the token has been tampered with. A valid JWT signature means the header and payload have not been changed since signing. If even one character in the header or payload is different, the signature will not match. This is the core security guarantee of JWTs.
HS256 (HMAC-SHA256) uses a shared secret — both the signer and verifier need to know the same secret. It is simple but means the secret must be kept secure on both sides. RS256 uses RSA public/private key pairs — the private key signs, the public key verifies, so the verifier never needs the private key. ES256 uses elliptic curve cryptography (ECDSA) and is similar to RS256 but with smaller key sizes. For APIs serving third parties, RS256 or ES256 are preferred because you can publish the public key without exposing signing capability.
The exp claim is compared to the current time in your browser. If the token was issued with a short lifetime (common in development and testing) it may have already expired. The token is still decodeable and the claims are still readable — expiry only matters when your application validates the token. For testing, generate a new token with a future expiry, or use the sample token loaded by the Load Sample button which has a far-future expiry date.
nbf stands for "not before" — it is a Unix timestamp that defines the earliest time the token is valid. A token with nbf in the future should not be accepted yet. This is used for tokens that are issued in advance but should only become active at a specific time, for example a scheduled access token or a time-limited invitation link.

Related Tools

#
Hash Generator
Generate MD5, SHA-256 hashes
64
Base64 Encoder
Encode & decode Base64
{}
JSON Formatter
Format JSON data
🔗
URL Encoder
Encode URLs