JWT Decoder

Decode and inspect JSON Web Tokens

Paste Your JWT

What is a JWT?

A JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. It consists of three parts: Header, Payload, and Signature.

Common Payload Claims:

iss (Issuer) - Who issued the token
sub (Subject) - The subject of the token (usually user ID)
aud (Audience) - Intended recipient of the token
exp (Expiration) - When the token expires
iat (Issued At) - When the token was issued
nbf (Not Before) - When the token becomes valid

Frequently Asked Questions

What is a JWT (JSON Web Token)?

A JWT is a compact, URL-safe token format used for securely transmitting information between parties. It consists of three parts: a header (algorithm info), payload (claims/data), and signature (verification). JWTs are commonly used for authentication and authorization.

Is it safe to decode JWTs in a browser?

Yes, decoding a JWT is safe because the header and payload are only base64-encoded, not encrypted. However, never share tokens containing sensitive data. Our decoder runs entirely in your browser and never sends your tokens to any server.

How do I know if my JWT has expired?

JWTs typically contain an "exp" (expiration) claim in the payload with a Unix timestamp. Our decoder automatically checks this claim and displays whether your token is valid or expired, along with the exact expiration date and time.

What are common JWT claims like iss, sub, and aud?

Common claims include: iss (issuer) - who created the token, sub (subject) - the user ID, aud (audience) - intended recipient, exp (expiration time), iat (issued at time), and nbf (not before time). Custom claims can also be added.

Can this tool verify JWT signatures?

This tool decodes and displays JWT contents but does not verify signatures, as that requires the secret key or public key used to sign the token. Signature verification should be done server-side where secrets are securely stored.

Understanding JSON Web Tokens in Depth

JSON Web Tokens (JWT) are an open standard defined in RFC 7519 for securely transmitting information between parties as a compact, self-contained JSON object. JWTs are widely used in modern web applications for authentication and authorization. Unlike traditional session-based authentication that requires server-side storage, JWTs are stateless: all the information the server needs is embedded in the token itself, making them ideal for distributed systems, microservices architectures, and single-page applications.

JWT Structure: Header.Payload.Signature

Every JWT consists of three parts separated by dots. Each part is Base64URL-encoded. Here is an example of a decoded JWT structure:

Header (algorithm and token type):

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload (claims and user data):

{
  "sub": "1234567890",
  "name": "Jane Developer",
  "email": "jane@example.com",
  "role": "admin",
  "iat": 1709251200,
  "exp": 1709337600
}

Signature (verification):

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret
)

Standard JWT Claims

The JWT specification defines several registered claim names that provide a standard set of metadata about the token:

iss (Issuer): Identifies the principal that issued the JWT, such as your authentication server or identity provider.
sub (Subject): Identifies the subject of the JWT, typically the user ID. This is the most common way to associate a token with a specific user.
aud (Audience): Identifies the intended recipients of the token. The receiving service should verify it is the intended audience.
exp (Expiration Time): A Unix timestamp after which the token must not be accepted. This is critical for limiting the window of a compromised token.
iat (Issued At): A Unix timestamp indicating when the token was created, useful for determining the age of a token.
nbf (Not Before): A Unix timestamp before which the token must not be accepted, useful for tokens that should only become active at a future time.
jti (JWT ID): A unique identifier for the token, which can be used to prevent token replay attacks.

When to Use JWTs

JWTs are best suited for stateless authentication where the server does not maintain session state. They excel in single sign-on (SSO) scenarios where one authentication service issues tokens that multiple services can verify independently. JWTs are also commonly used for API authorization, where a client includes the token in the Authorization header as a Bearer token. For inter-service communication in microservices, JWTs carry identity and permission data without requiring each service to query a central session store.

Security Considerations

Always use HTTPS to prevent token interception in transit. Set short expiration times and implement token refresh mechanisms to limit exposure from stolen tokens. Never store sensitive data like passwords in the payload, because the payload is only encoded, not encrypted, and anyone can decode it. Always validate the signature on the server side before trusting any claims in the token. Use strong signing keys and rotate them periodically. Be cautious with the alg header: always validate it server-side and never allow the "none" algorithm in production. Store tokens securely on the client side, preferring httpOnly cookies over localStorage to mitigate cross-site scripting (XSS) attacks.

Related Calculators

Developer