JWT Decoder

What is a JWT?

A JSON Web Token (JWT, pronounced "jot") is a compact, URL-safe token format defined in RFC 7519. JWTs are the industry standard for transmitting authentication and authorization information between parties. They are widely used in single sign-on (SSO) systems, OAuth 2.0 flows, and API authentication.

A JWT consists of three Base64URL-encoded parts separated by dots: a header, a payload, and a signature. The header specifies the signing algorithm (e.g., HS256, RS256). The payload contains claims — key-value pairs with information like user ID, permissions, and expiration time. The signature ensures the token has not been tampered with.

Common JWT claims

• sub: sub (Subject): Identifies the principal — usually a user ID or email address.
• iat: iat (Issued At): Unix timestamp indicating when the token was created.
• exp: exp (Expiration): Unix timestamp after which the token is no longer valid.
• iss: iss (Issuer): Identifies who issued the token (e.g., your authentication server).
• aud: aud (Audience): Identifies the intended recipient of the token (e.g., your API).

How to use this tool

Paste a JWT into the input field. The tool immediately decodes the header and payload, displaying the claims in a readable format. Expiration times are converted to human-readable dates. The tool also verifies the token structure and indicates if the format is invalid.

Is it safe to paste my JWT here?

Yes. This tool decodes the JWT entirely in your browser using JavaScript. No data is sent to any server. However, JWTs should always be treated as sensitive credentials — never share production tokens publicly, post them in chat messages, or commit them to version control.

How JWT authentication works

When a user logs in, the server creates a JWT containing the user's identity and permissions, signs it with a secret key, and returns it to the client. The client includes this token in the Authorization header of subsequent API requests. The server verifies the signature to ensure the token is authentic and has not been modified.

This approach is stateless — the server does not need to store session data in a database. All the necessary information is embedded in the token itself. This makes JWTs ideal for distributed systems, microservice architectures, and serverless applications where shared state is difficult to manage.

Common JWT mistakes

Storing sensitive data (passwords, credit card numbers) in the JWT payload is a critical mistake. The payload is only Base64-encoded, not encrypted — anyone with the token can decode and read it. Only store identifiers and non-sensitive claims in JWTs.

Using excessively long expiration times is another common error. A token that is valid for 30 days gives an attacker 30 days to use a stolen token. Keep access token lifetimes short (5–15 minutes) and use refresh tokens for long-lived sessions.

Frequently asked questions

What is the difference between HS256 and RS256?

HS256 uses a shared symmetric secret — the same key signs and verifies the token. RS256 uses an asymmetric key pair — a private key signs and a public key verifies. RS256 is preferred for distributed systems because the verification key can be shared publicly without compromising security.

Can a JWT be revoked?

JWTs are stateless, so they cannot be revoked directly. Common workarounds include maintaining a server-side blocklist of revoked token IDs, using short expiration times, or rotating signing keys. For immediate revocation needs, consider using opaque tokens with server-side session storage instead.