Decode a JSON Web Token (JWT)

What is a JWT (JSON Web Token)?

A JSON Web Token, abbreviated as JWT (pronounced "jot"), is a compact format defined by RFC 7519 for transporting a series of claims between two parties. The JWT is today the dominant format to carry an authenticated identity in an HTTP API. A JWT looks like an ASCII string made of three segments separated by dots:

header.payload.signature

Each segment is encoded in Base64URL, a variant of Base64 without = padding and that replaces + with - and / with _ so that it can travel in a URL or an HTTP header without further escaping.

Anatomy of a JWT

A JSON Web Token is composed of three distinct parts, each playing a precise role in the authentication mechanism:

1. Header

The header is a JSON object that describes how the token is signed. It contains at least:

• alg (algorithm): the signature algorithm used. Typical values: HS256, RS256, ES256, EdDSA.
• typ (type): the token type, almost always "JWT".
• kid (key ID): optional, identifies which key should be used to verify the signature. Useful when there is a pool of keys in rotation (JWKS).

2. Payload

The payload contains the claims, that is, the assertions the issuer makes about the user or the session. RFC 7519 defines seven standard claims (registered claims):

• iss (issuer): who issued the token, for example "https://accounts.google.com".
• sub (subject): who the token belongs to, in practice the user identifier.
• aud (audience): who the token is intended for. Prevents a token issued for API A from being accepted by API B.
• exp (expiration time): Unix timestamp after which the token is no longer valid.
• nbf (not before): timestamp before which the token is not yet active.
• iat (issued at): token issuance timestamp.
• jti (JWT ID): unique identifier of the token, used for revocation and replay prevention.

On top of these standard claims, applications usually add custom claims (roles, scope, tenant_id, email, permissions...).

3. Signature

The signature is a cryptographic digest computed over base64url(header) + "." + base64url(payload) using a key. It is what proves that no one has modified the header or the payload since issuance. The most common algorithms:

• HS256 / HS384 / HS512: symmetric HMAC-SHA signature. A secret key shared between issuer and verifier. Simple, but unsuited as soon as there is more than one consumer.
• RS256 / RS384 / RS512: asymmetric RSA signature. The issuer signs with its private key, any consumer verifies with the matching public key. De facto standard for OAuth2 and OpenID Connect.
• ES256 / ES384 / ES512: asymmetric ECDSA signature. Same properties as RS256 but with much shorter keys and signatures.
• EdDSA (Ed25519): modern asymmetric signature, fast and compact.

Again: the signature protects integrity, not confidentiality. The payload remains readable by anyone who has the token.

Why decode a JWT?

The jwt token decode operation answers several concrete needs for a developer or a security engineer:

• Authentication debugging: your API returns a 401 or 403, you want to see what is actually in the payload (sub, scope, roles, exp) rather than guess.
• Verify the claims: confirm that a token does contain the expected claim (for example tenant_id or permissions) before looking elsewhere in the authorisation chain.
• Read the expiry: convert the exp timestamp to a human date to confirm that a token is indeed expired, or on the contrary that it should still be valid.
• Security audit: ensure that a third-party service does not leak sensitive information in the payload (emails, internal identifiers, personal data).
• Training and understanding: see concretely what a JSON Web Token coming out of an OAuth provider (Google, Auth0, Keycloak, AWS Cognito) looks like to grasp the mechanics without diving into the docs.
• Public token exploration: inspect a JWT found in logs, in a cookie or in an interceptable OAuth exchange.

Decoder vs Verifier: the critical distinction

The two operations look similar but they have nothing to do with each other in terms of security guarantees:

• Decoding a JWT means splitting the string on the . and applying inverse Base64URL to the first two segments. It is a simple read, within reach of any three-line script. No signature verification is performed.
• Verifying a JWT means recomputing the signature from the header, the payload and a key, then comparing the result to the signature present in the token. That is what guarantees the token has not been tampered with.

Practical conclusion: decoding does not mean trusting. Until the signature has been verified with the right key, the payload content can be totally bogus. For the trust phase, use our JWT Verifier.

How to use it

1. Grab the JWT to inspect, for example from an Authorization: Bearer <jwt> header, from a session cookie, from the browser's localStorage, or from an application log.
2. Paste the full string into the input field. The three segments must stay separated by dots.
3. The tool immediately displays the decoded header as formatted JSON, with the algorithm and the type.
4. The payload is then decoded and displayed. You see every standard and custom claim there.
5. The tool also reports the signature information (declared algorithm, length), without verifying it.
6. To confirm the token has not been tampered with, switch to our JWT Verifier with the expected public key or secret.

The entire decoding runs in your browser in JavaScript: your token is never sent to our servers.

JWT and security: pitfalls to avoid

A few golden rules to use JWTs properly in production:

• Always verify the signature server-side before granting any right. Our JWT Verifier illustrates exactly that operation.
• Prefer RS256 or ES256 to HS256 for public APIs. Asymmetric signing avoids sharing a secret between the issuer and each consumer.
• Always respect the exp claim. A JWT without expiry or with an overly distant expiry is a time bomb in case of a leak.
• Validate iss and aud server-side, to prevent a legitimate token issued for another service from being accepted by mistake.
• Refuse alg: "none" on verification. It is a classic flaw that lets an attacker forge any payload.
• Keep lifetimes short (15 minutes for example) and pair with a longer but server-side revocable refresh token.

Example of a decoded JWT

Here is a typical JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMiLCJuYW1lIjoiSm9obiIsImlhdCI6MTUxNjIzOTAyMn0.jrU9j8LZcRK2_BZjqXjU7lEpJbkqmXfTQIu9vT45j-I

Once decoded, here is its content:

// Header
{
  "alg": "HS256",
  "typ": "JWT"
}

// Payload
{
  "sub": "123",
  "name": "John",
  "iat": 1516239022
}

// Signature (binary, encoded in Base64URL)
HMACSHA256(
  base64url(header) + "." + base64url(payload),
  secret
)

Where to find a JWT to copy?

In practice, a JWT to decode most often comes from one of these locations:

• HTTP cookie: open the developer tools (F12), Application or Storage tab, then Cookies. Look for a cookie named access_token, jwt, session or similar.
• localStorage / sessionStorage: same panel, Local Storage section. Many SPAs store their token there under a token or auth key.
• Authorization header: Network tab, pick an API request, read the Authorization: Bearer <jwt> header. Copy only the part after Bearer .
• Server logs: a JWT sometimes appears in the logs of a gateway or a reverse proxy (to avoid in production, but useful for debugging).

Frequently asked questions

Example request

curl -X POST https://cdrn.fr/api/v1/tools/jwt-decoder/execute \
  -H "Content-Type: application/json" \
  -d '{"token":"..."}'

Input schema

Endpoints

• GET https://cdrn.fr/api/v1/tools - lists every available tool
• GET https://cdrn.fr/api/v1/tools/jwt-decoder - returns the schema for this tool
• POST https://cdrn.fr/api/v1/tools/jwt-decoder/execute - runs this tool with a JSON payload