How to Decode & Inspect JWTs: Complete Guide to Header, Payload, Signature & Security Claims

JSON Web Tokens (JWT, defined in RFC 7519) are the dominant standard for stateless authentication and authorization across modern single-page applications, microservices, and OAuth 2.0 / OpenID Connect identity workflows. When debugging API integration issues, inspecting the token's payload is usually the first troubleshooting step.

Anatomy of a JWT: Three Dots, Three Sections

A compact JWT is a single string consisting of three Base64URL-encoded JSON objects separated by periods (`.`):

`header.payload.signature`

- **Header**: Specifies the token metadata, including the signing algorithm (`alg`, e.g., `HS256`, `RS256`, `EdDSA`) and token type (`typ: "JWT"`).

- **Payload (Claims)**: Contains the identity claims, user permissions, and timestamps.

- **Signature**: A cryptographic hash computed over `base64Url(header) + "." + base64Url(payload)` using a secret or private key.

Standard Registered Claims You Must Know

RFC 7519 defines several standard claims that every developer should understand:

- `sub` (Subject): The unique identifier of the authenticated user or machine.

- `iss` (Issuer): The identity provider that issued the token (e.g., `https://accounts.google.com` or `https://auth.company.com`).

- `aud` (Audience): The intended recipient API of the token.

- `exp` (Expiration Time): Unix timestamp after which the token is invalid. Decoders flag expired tokens immediately.

- `iat` (Issued At): Unix timestamp recording when the token was signed.

- `nbf` (Not Before): Unix timestamp before which the token must not be accepted.

Decoding vs. Verifying: A Vital Security Distinction

Anyone with access to a JWT can decode the Header and Payload in a browser because Base64URL is merely an encoding scheme, not encryption! Decoding does not require a secret key.

However, your backend API must never trust the decoded payload until it has cryptographically **verified the signature** against the server's secret HMAC key or the issuer's public JWKS certificate. Accepting unverified claims allows attackers to forge administrative roles.

Common Security Pitfalls

- **The "alg": "none" vulnerability**: Flawed JWT libraries historically accepted tokens where the algorithm was set to "none", allowing attackers to strip the signature entirely.

- **Leaking Sensitive Data**: Never store sensitive passwords, social security numbers, or encryption keys in a JWT payload, as it can be read by anyone inspecting browser network logs.

- **Storage Risks**: Storing access tokens in browser `localStorage` leaves them vulnerable to Cross-Site Scripting (XSS) extraction. Prefer `HttpOnly`, `SameSite=Lax` cookies for browser-based session persistence.

Inspect Tokens Privately in Your Browser

Never paste production access tokens or customer credentials into online decoders that send data to external cloud servers. Toolstack's free [JWT Decoder](/en/jwt-decoder) operates 100% client-side in browser memory with zero network requests.