What is a JWT Token?
A JWT, or JSON Web Token, is a compact token format used to share claims between systems. It is common in authentication, API authorization, single sign-on, and session-like workflows. A server can issue a JWT after login, and the client can send that token with future API requests. The receiving service can then read the token claims and decide whether the request should be allowed.
JWTs are popular because they are small, URL-safe, and easy to pass in HTTP headers. They can include user identifiers, roles, scopes, issue time, expiry time, issuer, audience, and custom application claims. This decoder lets you inspect those claims without sending the token anywhere.
JWT Structure — Header, Payload, Signature
A JWT usually has three parts separated by dots. The first part is the header, which describes the token type and signing algorithm. The second part is the payload, which contains claims such as subject, issue time, expiration time, issuer, and any custom data. The third part is the signature, which helps the server detect whether the token has been modified.
The header and payload are Base64URL encoded, not encrypted by default. That means anyone who receives the token can decode and read them. The signature is used for integrity, but verification requires the secret key or public key. This tool shows the signature string but does not claim to verify it.
Common JWT Claims Explained
The sub claim usually identifies the subject, often a user ID. The iat claim means issued at and tells when the token was created. The exp claim means expiration and is one of the most important security claims because it limits how long a token can be used. The nbf claim means not before and defines a time before which the token should not be accepted.
Other common claims include iss for issuer, aud for audience, jti for token ID, and application-specific claims like roles, permissions, plan names, tenant IDs, or feature flags. Custom claims are useful, but sensitive data should not be placed in a JWT unless the token is encrypted.
JWT Security Best Practices
Every production JWT should have an expiration time. Long-lived tokens increase risk if they are leaked. Avoid the none algorithm and treat unsigned tokens as dangerous unless you have a very specific internal reason. Prefer strong algorithms and validate expected issuer, audience, subject, and expiry on the server side. Never trust decoded JWT data only because it looks valid in the browser.
Store tokens carefully. Avoid placing high-value tokens in places where scripts, logs, browser extensions, or third-party tools can read them. Rotate signing keys when needed, keep secrets private, and use HTTPS everywhere. If using refresh tokens, keep them separate and protect them more strictly than short-lived access tokens.
FAQ
Does this JWT decoder send my token to a server?
No. Decoding and analysis run in your browser with plain JavaScript. The token is not uploaded by this tool.
Can this verify the JWT signature?
No. Signature verification requires the secret key or public key. This page decodes and audits visible token structure only.
Is JWT payload encrypted?
Usually no. Standard JWT payloads are encoded, not encrypted, so avoid storing passwords, secrets, or private data inside them.
What does an expired JWT mean?
An expired JWT should no longer be accepted by the server. If a server accepts expired tokens, that is a security issue.
Why does the analyzer warn about missing claims?
Claims like exp, iat, and sub help make tokens easier to validate, trace, and limit. Missing claims may not always be fatal, but they deserve review.