JWT Decoder

Welcome to the JWT Decoder, a powerful online tool for developers to decode and inspect JSON Web Tokens (JWTs) instantly. Whether you are debugging authentication issues, verifying token claims, or learning about JWT structure, this tool provides clear, color-coded visualization of all token components without sending any data to external servers.

What is a JSON Web Token (JWT)?

A JSON Web Token (JWT, pronounced "jot") is an open standard (RFC 7519) that defines a compact, self-contained method for securely transmitting information between parties as a JSON object. JWTs are widely used for:

• Authentication: After a user logs in, each subsequent request includes a JWT, allowing access to routes, services, and resources permitted with that token.
• Information Exchange: JWTs can securely transmit information between parties because they can be signed using secret keys (HMAC) or public/private key pairs (RSA, ECDSA).
• Authorization: Servers can verify token claims to determine user permissions without querying a database for each request.

JWT Structure Explained

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

1. Header (Red)

The header typically contains two pieces of information:

• alg: The signing algorithm used (e.g., HS256, RS256, ES256)
• typ: The token type, which is always "JWT"

2. Payload (Purple)

The payload contains the claims - statements about the user and additional metadata. There are three types of claims:

• Registered claims: Predefined claims like iss (issuer), exp (expiration), sub (subject), aud (audience)
• Public claims: Custom claims registered in the IANA JSON Web Token Registry or defined as URIs
• Private claims: Custom claims agreed upon between parties (e.g., user_id, role)

3. Signature (Blue)

The signature is created by combining the encoded header, encoded payload, a secret key, and the algorithm specified in the header. It ensures the token has not been tampered with.

Common JWT Claims Reference

JWT Signing Algorithms

Symmetric Algorithms (HMAC)

• HS256: HMAC using SHA-256 - Same secret key for signing and verification
• HS384: HMAC using SHA-384
• HS512: HMAC using SHA-512

Asymmetric Algorithms (RSA/ECDSA)

• RS256: RSA signature with SHA-256 - Private key signs, public key verifies
• RS384: RSA signature with SHA-384
• RS512: RSA signature with SHA-512
• ES256: ECDSA using P-256 curve and SHA-256
• ES384: ECDSA using P-384 curve and SHA-384
• ES512: ECDSA using P-521 curve and SHA-512

Security Considerations

Decoding vs Verifying

Important: This tool decodes JWTs but does not verify them. Decoding simply reveals the Base64URL-encoded content, while verification requires the secret key to validate the signature. Never trust decoded data without server-side signature verification.

Best Practices

• Always verify signatures server-side before trusting any claims
• Use short expiration times (exp) - typically 15 minutes to 1 hour for access tokens
• Don't store sensitive data in the payload - it's encoded, not encrypted
• Use HTTPS to prevent token interception during transmission
• Validate the audience (aud) claim to prevent token misuse
• Use asymmetric algorithms (RS256, ES256) for distributed systems where multiple services need to verify tokens

Privacy & Security

This JWT Decoder operates entirely in your browser:

• No server transmission: Your JWT is never sent to any server
• Client-side processing: All decoding happens in JavaScript in your browser
• No data storage: We don't store, log, or track your tokens
• Open source logic: You can inspect the decoding logic in your browser's developer tools

Frequently Asked Questions

What is a JWT (JSON Web Token)?

A JSON Web Token (JWT) is an open standard (RFC 7519) for securely transmitting information between parties as a JSON object. JWTs are commonly used for authentication and authorization in web applications. A JWT consists of three parts: Header (algorithm and token type), Payload (claims/data), and Signature (verification).

Is it safe to decode JWTs in the browser?

Yes, decoding a JWT in the browser is safe because the header and payload are simply Base64URL encoded, not encrypted. However, remember that decoding does NOT verify the token's signature. Never trust decoded data without proper server-side signature verification. This tool decodes tokens entirely in your browser - no data is sent to any server.

What do the different parts of a JWT mean?

A JWT has three parts separated by dots: 1) Header - Contains the algorithm (alg) and token type (typ), typically HS256 or RS256 for signing. 2) Payload - Contains claims, which are statements about the user and additional data like expiration time (exp), issued at (iat), subject (sub), etc. 3) Signature - Created by signing the header and payload with a secret key, used to verify the token hasn't been tampered with.

Why can't I verify the signature with this tool?

Signature verification requires the secret key (for symmetric algorithms like HS256) or the public key (for asymmetric algorithms like RS256). Since this tool runs entirely in your browser for privacy, it cannot access your server's secret keys. To verify signatures, use server-side libraries like jsonwebtoken (Node.js), PyJWT (Python), or jwt-go (Go).

What are common JWT claims?

Common registered claims include: iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not before), iat (issued at), and jti (JWT ID). Custom claims can include user_id, email, roles, permissions, or any application-specific data. Time-based claims (exp, nbf, iat) are Unix timestamps.

Additional Resources

• JWT.io - Official JWT Introduction
• RFC 7519 - JSON Web Token Specification