JWT Decoder

Introduction

JSON Web Tokens (JWT) are an open standard defined in RFC 7519 that provide a compact and self-contained way to transmit information between parties as a JSON object. This information can be verified and trusted because it is digitally signed using a secret or a public/private key pair. JWTs are used extensively in modern web applications for authentication, authorization, and secure information exchange. When a user logs into a system, the server generates a JWT that encodes the user's identity and permissions, and the client presents this token with each subsequent request to prove their identity without needing to resend credentials.

Understanding what is inside a JWT is critical for debugging authentication issues, verifying token contents during development, and auditing security configurations. The JWT Decoder tool allows you to inspect the three parts of any JWT token: the header, which describes the signing algorithm and token type; the payload, which contains the claims or assertions about the entity; and the signature, which is used to verify the token has not been tampered with. This tool performs no validation or verification, making it a safe way to examine tokens during development and testing.

Developers working with OAuth 2.0, OpenID Connect, Firebase Authentication, Auth0, or any JWT-based authentication system will find this tool invaluable. Instead of manually decoding Base64URL strings or writing one-off scripts, you can paste a token and instantly see its full decoded contents. Security researchers and penetration testers also use JWT decoding to analyze token structure, identify weak algorithms, and inspect claims for sensitive data exposure. The transparent, read-only nature of this tool ensures you can examine tokens without any risk of modifying or replaying them.

How to Use

Using the JWT Decoder is straightforward. Paste a JWT token into the text input area, and the decoded header, payload, and signature appear instantly. The tool uses auto-calculation, so there is no button to click, and results update as you type or paste.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImFiYzEyMyJ9.eyJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJzdWIiOiJ1c2VyQGV4YW1wbGUuY29tIiwiYXVkIjoibXktYXBwIiwiZXhwIjoxNzE4ODg5NjAwLCJpYXQiOjE2MTg4ODk2MDAsImp0aSI6InRva2VuLWlkLTEyMyJ9.bKyYc3nLKVzP8WcGvC2KPlJXxmQ0hLRtXyV2jGi-qk

JWT Structure

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

header.payload.signature

Reference Table

Practical Tips

1. Never trust a JWT without verifying the signature. Decoding reveals the contents, but a forged token can contain arbitrary claims. Always verify the signature on the server side using the correct secret or public key before trusting any claims. Decoding alone provides no security guarantees.

2. Check the algorithm field carefully. Some attacks rely on algorithm confusion, where an attacker changes alg from RS256 to HS256, tricking the server into using the public key as an HMAC secret. Always validate that the algorithm matches what you expect and reject tokens with unexpected algorithm values.

3. Never store sensitive data in the payload. JWT payloads are base64-encoded, not encrypted. Anyone who possesses the token can decode and read all claims. Do not place passwords, credit card numbers, or personally identifiable information in the payload unless the token is also encrypted (JWE).

4. Use HTTPS for all token transmission. JWTs are bearer tokens, meaning anyone who holds the token can present it as proof of identity. Transmitting tokens over unencrypted HTTP exposes them to interception through man-in-the-middle attacks, compromising the entire authentication system.

5. Validate expiration on every request. The exp claim should always be checked server-side. Tokens with no expiration or a suspiciously long lifetime may indicate a security issue. Implement short-lived access tokens (15-60 minutes) with longer-lived refresh tokens for the best balance of security and user experience.

6. Set appropriate audience restrictions. The aud claim limits which services can accept a token. When building microservices, ensure each service validates that the token's audience includes the service's identifier. Services should reject tokens issued for other services, preventing token reuse across service boundaries.

Limitations

This JWT Decoder performs no signature verification. It decodes the base64-encoded header and payload and displays them as formatted JSON, but it does not validate whether the signature matches the expected value. Decoding alone cannot determine if a token is authentic or forged.

The tool also does not check expiration times, validate claims against any schema, or verify that the token adheres to any particular profile of JWT usage. A token may appear valid when decoded but could be expired, issued for a different audience, or signed with an unexpected algorithm.

Base64URL decoding assumes the input uses URL-safe characters. Standard Base64 strings that use + and / will decode incorrectly unless they are converted first. This tool processes the header and payload sections as Base64URL, which is the standard encoding format for JWT per RFC 7515. If a token was constructed with standard Base64, the decoded output may contain garbled characters.

The signature is displayed as a raw Base64URL string and is truncated for display purposes. Full signature verification requires the original signing key and is outside the scope of this tool. For production debugging, use the JWT libraries available for your programming language or visit the official JWT debugging tools maintained by your authentication provider.

Frequently Asked Questions

What is a JWT and why is it used?

A JSON Web Token (JWT) is a compact, URL-safe token format defined by RFC 7519. It is used for authentication and secure information exchange between parties. JWTs are self-contained, meaning they carry all necessary user information within the token itself, reducing the need for database lookups on every request.

Can I verify a JWT signature with this tool?

No. This tool only decodes the header and payload. Signature verification requires the original signing key and cryptographic operations that are not performed here. Use your server-side JWT library or authentication provider tools for verification.

How is a JWT different from a session cookie?

Session cookies store a session ID on the client, and the server maintains session state in a database or cache. JWTs are stateless: all user information is encoded in the token itself, so the server does not need to look up session data. JWTs scale better horizontally but cannot be revoked easily without a blocklist.

Is it safe to decode a JWT I do not recognize?

Yes, because decoding only reads the base64-encoded content. No signature verification, network requests, or data modification occurs. The tool works entirely in your browser and does not send the token anywhere. However, treat the decoded contents with appropriate caution regarding sensitive information.

Where should I store JWTs in a web application?

JWTs should be stored in an HTTP-only, Secure, SameSite cookie for the best security against cross-site scripting (XSS) attacks. Local storage is convenient but vulnerable to XSS. Session storage is cleared when the tab closes and is suitable for single-session tokens. Never store tokens in URLs or in client-side JavaScript variables accessible to third-party scripts.

What is the difference between JWT and refresh tokens?

An access token (usually a JWT) is short-lived, often expiring in 15-60 minutes, and grants access to protected resources. A refresh token is long-lived, typically opaque (not a JWT), and used solely to obtain new access tokens without requiring the user to re-authenticate. Refresh tokens are stored more securely and can be revoked independently.

What does the "alg": "none" header mean?

The "none" algorithm means the JWT has no signature. This is used in contexts where integrity protection is not needed, such as public key infrastructure tokens sent over mutually authenticated TLS. Accepting "none" tokens in an authentication context is extremely dangerous and a common security vulnerability.

How are JWTs different from JSON Web Encryption (JWE)?

JWT (signed) ensures data integrity and authenticity but the payload is readable by anyone who decodes it. JWE (encrypted) provides confidentiality, making the payload unreadable without the decryption key. For sensitive information, use JWE or transmit JWTs over HTTPS only. JWTs and JWEs can be combined: a JWT can be nested inside a JWE to provide both signing and encryption.

Can a JWT contain multiple audiences?

Yes. The "aud" claim can be a string (single audience) or an array of strings (multiple audiences). When validating, the server should check that its own identifier is included in the audience list. This is common in microservice architectures where a token issued by an authentication gateway is valid across multiple backend services.

What happens if a JWT expires mid-request?

The server rejects the token and returns a 401 Unauthorized response. The client must obtain a new token, typically using a refresh token or by redirecting the user to re-authenticate. Most OAuth 2.0 implementations handle this transparently by refreshing the token before it expires using the refresh token grant.

How do I decode a JWT in my programming language?

JavaScript: JSON.parse(atob(token.split(".")[1])). Python: base64.urlsafe_b64decode(token.split(".")[1] + "=="). Java: new String(Base64.getUrlDecoder().decode(parts[1])). All languages have official or well-maintained JWT libraries that handle decoding, verification, and validation.

What is the maximum size of a JWT?

JWTs have no hard size limit, but most servers impose a maximum header size (typically 8-16 KB). A very large payload can cause performance issues because the token is sent with every request. Keep payloads small by including only essential claims (subject, expiration, essential roles) and look up additional data server-side.

References

1. [1]IETF RFC 7519: JSON Web Token (JWT) — The official specification defining JWT structure, claims, and usage.
2. [2]IETF RFC 7515: JSON Web Signature (JWS) — Defines the JWS specification that JWTs use for signing and Base64URL encoding.
3. [3]jwt.io — Official JWT debugging tool with library support and algorithm reference (maintained by Auth0).
4. [4]Auth0: JSON Web Token Handbook — Comprehensive guide to JWT structure, security best practices, and common vulnerabilities.
5. [5]OWASP: JSON Web Token Cheat Sheet — Security guidelines for JWT implementation, including algorithm confusion prevention and key management.
6. [6]IANA JSON Web Token Claims Registry — Complete registry of registered claim names and their definitions.