JWT Decoder - Decode JSON Web Tokens Online

Decode and inspect JSON Web Tokens instantly. View the header, payload claims, expiration status, and signature. Runs entirely in your browser.

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 way to securely transmit information between parties as a JSON object. JWTs are widely used in modern web applications for authentication, authorization, and information exchange. Unlike traditional session-based authentication where the server stores session data, JWTs carry all the necessary information within the token itself, making them stateless and scalable.

JWTs are digitally signed using a secret key (with HMAC algorithms) or a public/private key pair (with RSA or ECDSA algorithms). This signature ensures that the token has not been tampered with after it was issued. While the content of a JWT is not encrypted by default — it is merely Base64URL-encoded — the signature provides integrity verification. Anyone can read the contents of a JWT, but only the party with the secret or private key can create a valid signature.

JWT Structure: Header, Payload, and Signature

A JWT consists of three parts separated by dots (.): the header, the payload, and the signature. Each part is Base64URL-encoded, and the three parts are concatenated to form the complete token. The resulting string looks like xxxxx.yyyyy.zzzzz, where each section of x, y, and z characters represents one of the three parts.

Header

The header typically contains two fields: the token type (typ), which is almost always "JWT", and the signing algorithm (alg) being used. Common algorithms include HS256 (HMAC with SHA-256), RS256 (RSA with SHA-256), and ES256 (ECDSA with SHA-256). The header is a JSON object that gets Base64URL-encoded to form the first part of the token.

Payload

The payload contains the claims — statements about the user and additional metadata. Claims are categorized into three types: registered claims (predefined by the JWT standard, such as iss, sub, exp, and iat), public claims (defined by users of JWTs, registered in the IANA JSON Web Token Claims registry or defined as URIs), and private claims (custom claims agreed upon between parties, such as user roles or permissions).

Signature

The signature is created by taking the encoded header, the encoded payload, a secret key, and the algorithm specified in the header. For example, with HMAC SHA-256, the signature is computed as: HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret). The signature is used to verify that the message was not altered and, in the case of tokens signed with a private key, to verify the identity of the sender.

Common JWT Claims

The JWT specification defines several registered claim names that provide useful information about the token. While none of these claims are mandatory, they are widely used in practice:

iss (Issuer): Identifies the principal that issued the JWT. This is typically a URL or identifier of the authentication server, such as https://auth.example.com.
sub (Subject): Identifies the subject of the JWT — usually the user ID or email address of the authenticated user.
aud (Audience): Identifies the recipients that the JWT is intended for. This prevents tokens issued for one service from being used on another.
exp (Expiration Time): A Unix timestamp indicating when the token expires. After this time, the token should be rejected. Short expiration times limit the window of vulnerability if a token is compromised.
nbf (Not Before): A Unix timestamp indicating the earliest time at which the token should be accepted. Useful for tokens that are pre-issued but should not be used until a specific time.
iat (Issued At): A Unix timestamp indicating when the token was issued. This can be used to determine the age of the token.
jti (JWT ID): A unique identifier for the token, used to prevent the same JWT from being used more than once (replay protection).

JWT vs Session Cookies

Traditional web authentication uses server-side sessions: when a user logs in, the server creates a session record and sends a session ID cookie to the browser. Every subsequent request includes this cookie, and the server looks up the session to identify the user. This approach works well but requires server-side storage and can become a bottleneck in distributed systems where multiple servers need to share session data.

JWTs take a different approach. The token itself contains all the information needed to identify the user and their permissions. The server does not need to store any session data — it simply verifies the token's signature and reads the claims. This makes JWTs particularly well-suited for microservices architectures, single-page applications (SPAs), mobile apps, and any scenario where stateless authentication is preferred. The server can verify a JWT without making a database query, which can significantly improve performance at scale.

However, JWTs come with their own trade-offs. Because tokens are self-contained, they cannot be easily revoked before their expiration time. If a JWT is compromised, it remains valid until it expires. Session cookies, on the other hand, can be invalidated instantly by deleting the session from the server. Many applications address this by using short-lived JWTs combined with refresh tokens, or by maintaining a server-side deny list of revoked token IDs.

Security Considerations

JWTs are powerful but must be used carefully to avoid security vulnerabilities. Here are the most important security considerations when working with JWTs:

Never store sensitive data in the payload. JWT payloads are Base64URL-encoded, not encrypted. Anyone with access to the token can decode and read the payload. Do not include passwords, credit card numbers, or other sensitive information. Use JWE (JSON Web Encryption) if you need to encrypt the payload.
Always verify the signature. Before trusting the claims in a JWT, always verify its signature on the server side using the appropriate key. Never skip signature verification, as this would allow attackers to forge tokens with arbitrary claims.
Use strong signing algorithms. Prefer RS256 or ES256 (asymmetric algorithms) over HS256 (symmetric) in production systems. With asymmetric algorithms, only the authentication server needs the private key, while any service can verify tokens using the public key.
Set short expiration times. Use the exp claim with a short duration (minutes to hours, not days or weeks). Combine with refresh tokens for seamless user experience. Short-lived tokens minimize the impact of a compromised token.
Protect against the "alg: none" attack. Some JWT libraries accept tokens with "alg": "none", which means no signature is required. Always validate the algorithm and reject tokens with unexpected or missing algorithms.
Store tokens securely on the client. Store JWTs in httpOnly cookies rather than localStorage to prevent cross-site scripting (XSS) attacks from stealing the token. If you must use localStorage, ensure your application has robust XSS protections.

When to Use JWTs

JWTs are an excellent choice in several scenarios. They work particularly well for single sign-on (SSO), where one authentication service issues tokens that multiple applications can verify independently. They are ideal for APIs that serve mobile apps, since mobile clients can easily store and send tokens in HTTP headers. They are also well-suited for microservices architectures where you want to avoid shared session state between services.

JWTs may not be the best choice when you need instant token revocation, when the payload needs to contain large amounts of data (since the token is sent with every request), or when you are building a simple server-rendered application where session cookies would be simpler and more straightforward. Evaluate your specific requirements before choosing between JWT-based authentication and traditional session-based approaches.

How This Tool Works

This JWT decoder runs entirely in your browser using JavaScript. It splits the JWT by the dot separator, decodes each part from Base64URL encoding, and parses the header and payload as JSON. The tool displays the decoded header with the algorithm and token type, the payload with all claims, and the raw signature string. It also checks the exp claim to show whether the token is currently valid or expired, along with the exact expiration date and time difference.

No data is sent to any server — your tokens remain completely private. This tool is designed for debugging and inspection purposes. It does not verify the JWT signature, as that requires the secret or public key that was used to sign the token.

Frequently Asked Questions

What is a JSON Web Token (JWT)?

A JSON Web Token is a compact, URL-safe token format used to securely transmit information between parties as a JSON object. It consists of three parts separated by dots: a header specifying the algorithm and token type, a payload containing claims, and a signature used to verify the token has not been tampered with. JWTs are widely used for authentication and authorization in modern web applications.

Can this tool verify a JWT signature?

No. This tool decodes the header and payload, which are Base64URL-encoded and readable by anyone. Signature verification requires the secret key (for HMAC algorithms) or the public key (for RSA/ECDSA algorithms). Use a server-side library such as jsonwebtoken (Node.js), PyJWT (Python), or java-jwt (Java) to verify signatures in production.

Is it safe to decode a JWT in the browser?

Yes, it is safe to decode a JWT in the browser. JWT headers and payloads are only Base64URL-encoded, not encrypted, so the data is already readable by anyone who has the token. This tool processes everything locally in your browser and never transmits your token to any server. That said, you should never include sensitive information like passwords in a JWT payload in the first place.

Related Tools

Base64 Encoder/Decoder -- Encode or decode Base64 strings.
Hash Generator -- Generate MD5, SHA-256, and other cryptographic hashes.
JSON Formatter -- Format and validate JSON data.