Free JWT Decoder

About This Tool

JSON Web Tokens (JWT) are the standard for secure data transmission in modern web apps. But they are encoded strings, making them impossible to read without decoding. Our Free JWT Decoder instantly parses the token to reveal the <strong>Header</strong> (algorithm info) and <strong>Payload</strong> (user data/claims). It helps you debug authentication issues, verify token contents, and check expiration times without sending your token to a server.

What is a JWT?

A JSON Web Token is a compact, URL-safe means of representing claims to be transferred between two parties. It consists of three parts separated by dots (.):

Header: Algorithm and token type.
Payload: The data (claims) like user ID, roles, and expiration.
Signature: Verifies the token hasn't been tampered with.

Common JWT Claims

sub (Subject): Whom the token refers to (usually User ID).
iss (Issuer): Who created the token.
exp (Expiration): Timestamp when the token expires.
iat (Issued At): Timestamp when the token was created.
aud (Audience): Intended recipient of the token, often the API or service domain.
nbf (Not Before): Token is invalid before this timestamp, useful for delayed activation.
jti (JWT ID): Unique identifier for the token, used to prevent replay attacks.

Custom claims are added by the issuing application. Common examples include user roles, email addresses, organization IDs, and feature flags. These custom claims ride alongside the standard registered claims and can contain any JSON-serializable data the application needs.

JWT Security Best Practices

JWTs are powerful but require careful handling to maintain security:

Always validate the signature: Decoding a JWT reveals its contents, but only signature verification confirms it has not been tampered with. Never trust a JWT payload without first verifying the signature server-side.
Check expiration times: Always verify the exp claim before accepting a token. Expired tokens should be rejected immediately, even if the signature is valid.
Use short-lived tokens: Access tokens should expire in minutes, not hours or days. Pair them with refresh tokens for a better security posture.
Store tokens securely: Avoid storing JWTs in localStorage where they are vulnerable to cross-site scripting (XSS). HTTP-only cookies are generally safer for web applications.
Never put sensitive data in the payload: JWTs are encoded, not encrypted. Anyone can decode the payload without the secret key. Never include passwords, credit card numbers, or other secrets in JWT claims.

Frequently Asked Questions

Is this secure?

Yes. All decoding happens on your device and never leaves your computer. Your token is not sent to any server. However, you should never paste tokens containing highly sensitive secrets (if any) into public tools.

Why is the signature not verified?

Verifying the signature requires your secret key or public key. To protect your security, we do not ask for or process keys. This tool is for inspecting the contents of the token only. Signature verification should always be done server-side using your authentication library.

What do the "exp" and "iat" timestamps mean?

The "exp" (expiration) and "iat" (issued at) claims contain Unix timestamps representing seconds since January 1, 1970. For example, 1700000000 corresponds to November 14, 2023. You can convert these timestamps using any Unix time converter. The "exp" claim determines when the token becomes invalid, while "iat" records when it was created. If the current time exceeds "exp", the token should be rejected by the server.

Can I decode a JWT without the secret key?

Yes, and that is exactly what this tool does. The header and payload sections of a JWT are simply Base64URL-encoded JSON, meaning anyone can decode and read them. The secret key is only needed to verify the signature, which confirms the token was issued by a trusted source and has not been tampered with. This is why you should never put sensitive information like passwords directly into JWT claims.

Paste Encoded Token

Security Note