How to Decode JWT Tokens: Complete Guide 2026

What is a JSON Web Token?

A JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way to securely transmit information between parties as a JSON object. JWTs are digitally signed, meaning they can be verified and trusted. The token is composed of three Base64-encoded segments separated by dots: header.payload.signature. Each segment plays a distinct role in the token's structure and security model.

JWTs are widely used in modern web applications for stateless authentication, single sign-on (SSO), and API authorization flows like OAuth 2.0 and OpenID Connect. Their compact size makes them suitable for URL parameters, HTTP headers, and mobile environments where bandwidth is limited. Understanding how to decode and inspect JWTs is essential for developers, security engineers, and anyone working with API authentication.

Understanding JWT Structure

                        Complete JWT Example:

                        eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.

                        eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.

                        SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

The three parts of a JWT serve different purposes:

Header (first part): Contains metadata about the token, typically the type (JWT) and the signing algorithm (e.g., HS256, RS256, ES256). The header determines how the signature was created and must be verified.
Payload (second part): Contains the claims — statements about an entity (typically the user) and additional metadata. Claims can be registered (standardized like sub, iat, exp), public, or private. Never put sensitive information in the payload as it's only Base64-encoded, not encrypted.
Signature (third part): Created by taking the encoded header and payload, concatenating them with a dot, and signing the result with a secret key (HMAC) or private key (RSA/ECDSA). The signature verifies that the token hasn't been tampered with.

Security note: JWT header and payload are not encrypted — they are only Base64-encoded. Anyone with access to the token can read the contents. Never store passwords, API keys, or other secrets in a JWT payload.

Common JWT Use Cases

🔒

Authentication

After a user logs in, the server issues a JWT. The client sends this token with each subsequent request. The server validates the signature to authenticate the user without maintaining session state.

🔗

API Authorization

JWTs encode user roles and permissions in claims. APIs check these claims to enforce access control on specific endpoints, enabling fine-grained authorization without database lookups.

👥

Single Sign-On (SSO)

JWTs are the backbone of modern SSO systems. A user authenticates once with an identity provider, which issues a JWT. This token is then accepted by multiple service providers within the same ecosystem.

🔄

Information Exchange

JWTs securely transmit information between parties. Because they are signed, you can verify the sender's identity and ensure the content hasn't changed. This is useful for secure inter-service communication.

Step-by-Step: Decode a JWT

Copy Your JWT Token

Get the JWT token from your application. You can find it in your browser's local storage, an HTTP cookie, the Authorization header of API requests, or the URL fragment (common in OAuth flows).

Paste into the Decoder

Open the JWT Decoder tool and paste your token into the input field. The tool automatically parses the three Base64-encoded segments and displays the decoded header and payload as formatted JSON.

Inspect the Header

Review the decoded header to see the signing algorithm (alg) and token type. Common algorithms include HS256 (HMAC with SHA-256), RS256 (RSA with SHA-256), and ES256 (ECDSA with SHA-256).

Examine the Payload Claims

Review the decoded payload to understand the token's claims. Standard claims include sub (subject), iat (issued at), exp (expiration), and iss (issuer). Custom claims may include user roles, permissions, or other application-specific data.

Standard JWT Claims Reference

Claim	Full Name	Description
`iss`	Issuer	Identifies the principal that issued the JWT
`sub`	Subject	Identifies the subject of the JWT (usually the user ID)
`aud`	Audience	Identifies the recipients the JWT is intended for
`exp`	Expiration Time	Unix timestamp after which the JWT expires
`nbf`	Not Before	Unix timestamp before which the JWT is not valid
`iat`	Issued At	Unix timestamp when the JWT was issued
`jti`	JWT ID	Unique identifier for the JWT (prevents replay attacks)

Tip: The exp (expiration) claim is critical for security. A JWT without an expiration claim could be used indefinitely if stolen. Always check that the token hasn't expired before trusting its contents.

Best Practices for Working with JWTs

Never store secrets in the payload: JWT payloads are Base64-encoded, not encrypted. Anyone with the token can decode and read the claims. Use JWE (JSON Web Encryption) if you need confidentiality.
Always validate the signature server-side: Client-side tools can decode JWTs for debugging, but always verify the signature on your server before trusting the token's claims.
Check the algorithm: Verify that the token uses an expected algorithm. A known attack involves changing the algorithm from RS256 to HS256 and using the public key as the HMAC secret. Always validate the algorithm server-side.
Use short expiration times: Keep JWT lifetimes short (15-60 minutes for access tokens) to limit the damage if a token is compromised. Use refresh tokens for longer-lived sessions.
Use HTTPS exclusively: Always transmit JWTs over HTTPS to prevent token interception. A stolen JWT grants the attacker the same privileges as the legitimate user for the token's lifetime.
Implement token revocation: While JWTs are designed to be stateless, maintain a token blacklist or use short expiry with refresh tokens to handle scenarios like user logout or compromised tokens.

Limitations to Consider

This tool only decodes — it does not verify signatures: The JWT Decoder displays the Base64-decoded header and payload but does not validate the signature. Signature verification requires the secret key (for HMAC) or public key (for RSA/ECDSA).
No encryption: JWTs are signed, not encrypted. Anyone who intercepts a JWT can read its contents. For sensitive data, use JWE (JSON Web Encryption) or pass the token over HTTPS only.
Payload readability: Because the payload is only Base64-encoded, it is immediately readable by anyone. Avoid storing personally identifiable information (PII) or sensitive business data in JWT claims.
Debugging purposes only: The decoder is intended for development, debugging, and learning. Do not rely solely on decoded JWT data for security decisions — always perform server-side signature verification.

Security warning: This tool decodes the Base64-encoded parts of a JWT. It does NOT verify the cryptographic signature. Decoding a JWT does not mean the token is valid, authentic, or untampered. Always verify signatures server-side before trusting a JWT.

Frequently Asked Questions

What is a JWT token?

A JWT (JSON Web Token) is a compact, URL-safe token that represents claims between two parties. It consists of three Base64-encoded parts separated by dots: header, payload, and signature. JWTs are commonly used for authentication and API authorization.

Is it safe to decode a JWT?

Yes, decoding a JWT is safe because the header and payload are only Base64-encoded, not encrypted. Anyone with the token can read them. The security lies in the signature, which requires the secret key to generate and verify. Never put sensitive data in a JWT payload.

Can this tool verify JWT signatures?

No, this tool only decodes the Base64-encoded header and payload. Signature verification requires the secret key and is not performed by this tool. Use our JWT Generator for signing, or a server-side library for production verification.

What do the three JWT parts mean?

The header contains metadata like the signing algorithm (e.g., HS256) and token type (JWT). The payload contains the claims (statements about the user and metadata). The signature is created by signing the encoded header and payload with a secret key to verify integrity.

What happens if a JWT expires?

When a JWT's expiration time (exp claim) has passed, the token is no longer considered valid. The server rejects the token and the user must re-authenticate or use a refresh token to obtain a new JWT. This limits the window of vulnerability for stolen tokens.

Is my token data private when using this tool?

Yes, all decoding happens entirely in your browser. No data is sent to any server. Your tokens remain completely private and are never transmitted or stored anywhere.

Related JWT Tools

Enhance your JWT workflow with these complementary tools: