JWT Tokens Explained: How to Decode, Verify, and Debug JSON Web Tokens

What Is a JSON Web Token (JWT)?

A JSON Web Token (JWT, pronounced "jot") is a compact, URL-safe token format used to securely transmit information between parties as a JSON object. JWTs are the de facto standard for authentication and authorization in modern web applications, APIs, and microservices architectures. Defined in RFC 7519, JWTs are self-contained — they carry all the information needed to verify their authenticity and extract user claims without querying a database.

Anatomy of a JWT

Every JWT consists of three parts separated by dots (.):

• Header: A Base64URL-encoded JSON object specifying the token type and signing algorithm.
• Payload: A Base64URL-encoded JSON object containing the claims — the actual data the token carries.
• Signature: A cryptographic signature computed over the header and payload, ensuring the token has not been tampered with.

A typical JWT looks like this: eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.signature. The three sections are separated by periods, and each is independently Base64URL-decoded to reveal its JSON content.

The Header

The header typically contains two fields:

• alg: The signing algorithm — HS256 (HMAC-SHA256), RS256 (RSA-SHA256), or ES256 (ECDSA-SHA256) are the most common.
• typ: The token type, almost always JWT.

The Payload (Claims)

The payload contains claims — statements about the user and additional metadata. JWT defines three types of claims:

• Registered claims: Standardized fields like iss (issuer), sub (subject), aud (audience), exp (expiration), iat (issued at), and nbf (not before).
• Public claims: Custom claims defined in the IANA JSON Web Token Claims registry or using collision-resistant names.
• Private claims: Application-specific claims agreed upon between parties, such as userId, role, or permissions.

Critical: The payload is encoded, not encrypted. Anyone who has the token can decode the payload and read its contents. Never put sensitive data like passwords, credit card numbers, or personal identification numbers in a JWT payload.

The Signature

The signature is created by taking the encoded header and payload, concatenating them with a dot, and signing the result with a secret key (for HMAC) or a private key (for RSA/ECDSA). The recipient verifies the signature using the shared secret or the public key, confirming that the token was issued by a trusted party and has not been modified.

Common Signing Algorithms

HS256 (HMAC-SHA256)

A symmetric algorithm where the same secret key is used for both signing and verification. Simple to implement but requires both parties to share the secret. Best for single-server applications where the same service issues and verifies tokens.

RS256 (RSA-SHA256)

An asymmetric algorithm using an RSA key pair. The server signs with the private key; clients verify with the public key. Ideal for distributed systems where multiple services need to verify tokens without having access to the signing key. This is the most common algorithm for production systems and OpenID Connect providers.

ES256 (ECDSA-SHA256)

Another asymmetric algorithm using elliptic curve cryptography. Produces significantly smaller signatures than RS256 (64 bytes vs. 256 bytes) with equivalent security. Increasingly popular for mobile and IoT applications where token size matters.

How to Decode a JWT

Decoding a JWT — extracting the header and payload — is straightforward because these sections are simply Base64URL-encoded JSON. Decoding does not require any secret key. This is an important distinction: decoding reveals the content; verifying confirms its authenticity.

Our JWT Decoder tool instantly decodes any JWT in your browser. Paste a token, and the tool displays the header, payload, and signature in a clean, formatted view. It also highlights important fields like expiration time and shows whether the token is currently expired. Everything is processed client-side — your tokens are never sent to any server, making it safe for production tokens.

When to Decode JWTs

• Debugging authentication issues: Check the exp claim to see if a token is expired. Inspect the aud and iss claims to verify they match your expected values.
• Inspecting third-party tokens: When integrating with OAuth2 providers, decode the access token or ID token to verify the claims you are receiving.
• Development and testing: During API development, quickly inspect tokens to verify your authentication service is issuing them correctly.
• Security audits: Review what data is being exposed in tokens. Remember, anyone with the token can read the payload.

JWT Security Best Practices

JWTs are powerful but come with security considerations that developers must understand:

1. Always Verify the Signature

Never trust a JWT without verifying its signature. An unverified token could have been crafted by an attacker with arbitrary claims. Your server-side code must verify the signature before extracting and trusting any claims.

2. Set Short Expiration Times

JWTs cannot be revoked once issued (unless you maintain a blacklist, which defeats some of their purpose). Use short expiration times — 15 minutes for access tokens is a common practice — combined with refresh tokens for long-lived sessions.

3. Never Store Sensitive Data in the Payload

The payload is encoded, not encrypted. Treat it as public information. Do not include passwords, social security numbers, financial data, or any information that would be damaging if exposed.

4. Use HTTPS Exclusively

Transmit JWTs only over HTTPS. A JWT intercepted over HTTP gives an attacker full access to whatever the token authorizes.

5. Beware the "none" Algorithm Attack

A classic JWT vulnerability occurs when a server accepts the alg: "none" header, which specifies no signature at all. An attacker can forge a token with arbitrary claims and no signature. Always explicitly specify which algorithms your server accepts and reject none.

6. Validate All Standard Claims

Check exp (is it expired?), nbf (is it valid yet?), iss (was it issued by the expected authority?), and aud (is it intended for this service?). Skipping any of these checks opens the door to token misuse.

JWTs in OAuth 2.0 and OpenID Connect

JWTs play a central role in modern identity protocols. In OpenID Connect, the ID token is always a JWT, containing claims about the authenticated user. OAuth 2.0 access tokens are frequently (though not always) JWTs, especially in systems using self-contained tokens for stateless authorization.

When debugging OAuth flows, being able to decode and inspect these tokens is invaluable. Use our JWT Decoder to quickly examine tokens returned by identity providers like Auth0, Firebase, AWS Cognito, or any OpenID Connect-compliant service.

Decode Your Tokens Safely

Ready to inspect a JWT? Our free JWT Decoder runs entirely in your browser — paste your token and instantly see the decoded header, payload, and signature details. No server processing, no data collection, completely private. It is the safest way to inspect production tokens without exposing them to third-party services.