What is the difference between JWT decoding and verification?

Decoding a JWT means reading the header and payload by Base64-decoding them. Verification means checking that the signature is valid using the secret key (for HMAC algorithms) or the public key (for RSA/ECDSA algorithms). Decoding tells you what the token says; verification tells you whether the token is trustworthy. Never trust a JWT's contents without verifying the signature on the server side.

JWT Decoder - Free Online Tool

Q: What is a JSON Web Token (JWT)?

A JSON Web Token (JWT) is a compact, URL-safe token format used for securely transmitting information between parties. It consists of three Base64-encoded parts separated by dots: a header (specifying the algorithm and token type), a payload (containing claims like user identity and expiration), and a signature (used to verify the token has not been tampered with).

Q: Is it safe to decode JWTs in the browser?

Yes, decoding a JWT is completely safe because the header and payload are simply Base64-encoded, not encrypted. Anyone with the token can read them. The security of a JWT comes from the signature, which proves the token was issued by a trusted party. This tool decodes the token but does not verify the signature, which requires the secret key or public key.

Q: What are common JWT claims?

Standard JWT claims include: sub (subject - who the token is about), iss (issuer - who created the token), exp (expiration time as a Unix timestamp), iat (issued at - when the token was created), aud (audience - who the token is intended for), nbf (not before - token is not valid before this time), and jti (JWT ID - a unique identifier for the token).

Q: How do I know if a JWT is expired?

A JWT is expired when the current time is past the value in the exp (expiration) claim. The exp claim is a Unix timestamp representing the exact second when the token expires. This decoder automatically checks the expiration and tells you whether the token is still valid or has expired, along with the exact expiration date and time.

Paste a JSON Web Token to instantly decode the header, payload, and signature. See expiration status, algorithm, and all claims.

Understanding JSON Web Tokens

A JSON Web Token is a compact, self-contained mechanism for transmitting information between two parties as a JSON object. JWTs are widely used in modern web development for authentication, authorization, and information exchange. The token format was standardized in RFC 7519 and has become the dominant approach for stateless authentication in APIs and single-page applications.

Every JWT consists of three parts separated by dots: the header, the payload, and the signature. The header typically contains two fields: the signing algorithm (such as HS256 or RS256) and the token type (usually "JWT"). The payload carries the claims, which are statements about the user and additional metadata. The signature is created by encoding the header and payload, then signing them with a secret key or private key. This three-part structure gives JWTs their characteristic appearance: xxxxx.yyyyy.zzzzz.

Standard JWT Claims Explained

The JWT specification defines several registered claim names that have specific meanings. The sub (subject) claim identifies the principal the token represents, typically a user ID. The iss (issuer) claim identifies who created and signed the token, often a domain or service name. The exp (expiration time) claim sets the timestamp after which the token must be rejected. The iat (issued at) claim records when the token was generated.

Additional standard claims include aud (audience), which restricts which services should accept the token, nbf (not before), which prevents the token from being used before a certain time, and jti (JWT ID), which provides a unique identifier to prevent token replay attacks. Beyond these registered claims, applications commonly add custom claims like user roles, permissions, email addresses, or organization identifiers.

JWTs vs Session Cookies

Traditional session-based authentication stores session data on the server and sends a session ID cookie to the client. JWTs take the opposite approach: the token itself contains all the user information, and the server does not need to maintain session state. This makes JWTs ideal for distributed systems where multiple servers need to validate authentication without sharing session storage. Session cookies are simpler and give the server full control over session invalidation, while JWTs offer better scalability at the cost of more complex token management.

When to Use JWTs

JWTs excel in several scenarios. API authentication is the most common use case, where a client includes the JWT in the Authorization header of each request. Single Sign-On (SSO) systems use JWTs to pass authentication state between different applications without requiring users to log in again. Microservice architectures benefit from JWTs because each service can independently validate tokens without calling a central authentication service. JWTs are also useful for short-lived authorization grants, such as password reset links or email verification tokens.

Security Considerations

Never store sensitive information in a JWT payload. The payload is Base64-encoded, not encrypted, meaning anyone with the token can read its contents. Always verify signatures on the server side before trusting any claims in the token. Set reasonable expiration times to limit the window of vulnerability if a token is compromised. Use HTTPS exclusively when transmitting tokens to prevent interception. Consider using short-lived access tokens paired with refresh tokens for long-running sessions. Store tokens securely on the client side, preferring HttpOnly cookies over localStorage to prevent cross-site scripting attacks from stealing tokens.

Frequently Asked Questions

What is a JSON Web Token (JWT)?

A JWT is a compact, URL-safe token consisting of three Base64-encoded parts (header, payload, signature) separated by dots. It securely transmits claims between parties and is commonly used for API authentication.

Is it safe to decode JWTs in the browser?

Yes. The header and payload are only Base64-encoded, not encrypted. Security comes from the signature, which requires the secret key to verify. Decoding reveals the contents but does not compromise security.

What are common JWT claims?

Standard claims include sub (subject), iss (issuer), exp (expiration), iat (issued at), aud (audience), nbf (not before), and jti (unique token ID). Custom claims can carry any application-specific data.

How do I know if a JWT is expired?

Check the exp claim, which is a Unix timestamp. If the current time exceeds this value, the token is expired. This decoder automatically checks and displays the expiration status.

What is the difference between decoding and verification?

Decoding reads the header and payload by Base64-decoding them. Verification checks the signature using the secret or public key. Always verify signatures server-side before trusting token contents.

JWT Decoder

Embed This Calculator