What is a JSON Web Token (JWT)?
A JSON Web Token (JWT, pronounced "jot") is a compact, URL-safe token format defined in RFC 7519. It allows two parties to exchange claims — pieces of information represented as JSON key-value pairs — in a way that can be verified and trusted. JWTs are the dominant token format for modern web authentication, used by OAuth 2.0 flows, OpenID Connect, and countless API authentication systems.
Unlike opaque session tokens that require a server-side lookup, JWTs are self-contained. The token itself carries all the information the server needs to authenticate a request, which makes them especially useful in stateless, distributed architectures where multiple services need to verify identity without sharing a session store.
JWT Structure: Three Parts, Three Purposes
Every JWT consists of three Base64URL-encoded segments separated by dots (.):
- Header — a JSON object specifying the token type (
"typ": "JWT") and the signing algorithm ("alg": "HS256","RS256", etc.). The header tells the verifier how to validate the signature. - Payload — a JSON object containing the claims. This is where the actual data lives: who the token was issued to, when it expires, and any custom fields your application needs.
- Signature — computed by taking the encoded header and payload, concatenating them with a dot, and signing the result using the algorithm specified in the header along with a secret key (for HMAC) or a private key (for RSA/ECDSA). The signature ensures the token has not been tampered with.
Because the header and payload are merely Base64URL-encoded (not encrypted), anyone can decode and read them. The signature does not provide confidentiality — it provides integrity. This is why you should never put sensitive information like passwords or credit card numbers in a JWT payload unless you use JWE (JSON Web Encryption).
Common JWT Claims
RFC 7519 defines a set of registered claims with specific meanings:
iss(issuer) — identifies the principal that issued the token, typically a URL or service name.sub(subject) — identifies the subject of the token, usually a user ID.aud(audience) — identifies the intended recipients. A token meant forapi.example.comshould be rejected byapi.other.com.exp(expiration time) — a Unix timestamp after which the token must not be accepted. This tool shows a live countdown when anexpclaim is present.iat(issued at) — the Unix timestamp when the token was created.nbf(not before) — the token must not be accepted before this Unix timestamp.jti(JWT ID) — a unique identifier for the token, useful for preventing replay attacks.
Applications commonly add custom claims like roles, permissions, email, or org_id alongside the registered claims.
How JWT Authentication Works
A typical JWT authentication flow looks like this: the user submits credentials (username and password) to a login endpoint. The server verifies the credentials, generates a JWT containing the user's identity and permissions, signs it with a secret or private key, and returns it to the client. On subsequent requests, the client sends the JWT in the Authorization: Bearer <token> header. The server validates the signature, checks the expiration, and extracts the claims — all without a database lookup.
This stateless approach scales well because any server instance with the signing key can verify the token independently. The tradeoff is that JWTs cannot be easily revoked before they expire, which is why short expiration times combined with refresh tokens are a common pattern.
JWT vs. Session Cookies
Session cookies store a random session ID in the browser, and the server looks up session data in a database or cache. JWTs embed the session data directly in the token. Session cookies are simpler to revoke (delete the server-side session) and less vulnerable to XSS (HttpOnly cookies are invisible to JavaScript). JWTs excel in distributed systems, cross-domain authentication, and mobile apps where cookies are impractical. Many production systems use both: a JWT for service-to-service communication and an HttpOnly session cookie for the browser.
How to Use This JWT Decoder
- Paste a JWT token into the input field. The tool accepts the full three-part token.
- The header, payload, and signature are decoded and displayed instantly as formatted JSON.
- If the token contains timestamp claims (
iat,nbf,exp), they are converted to human-readable dates in the Timestamps section. - An
expclaim triggers a live validity indicator showing whether the token is still valid and a countdown to expiration. - Use the Copy buttons to copy individual sections. Share the URL to let others inspect the same token.
Frequently Asked Questions
What is a JWT?
A JSON Web Token (JWT) is a compact, URL-safe token format defined in RFC 7519. It consists of a header, payload, and signature separated by dots. JWTs are widely used for authentication — after login, the server issues a signed token that the client includes in subsequent requests to prove its identity.
Is JWT the same as encryption?
No. A standard JWT (JWS) is signed, not encrypted. The header and payload are Base64URL-encoded, so anyone can decode and read them. The signature only verifies integrity — that the token has not been tampered with. For encrypted tokens, the JWE (JSON Web Encryption) standard exists but is far less common.
What are JWT claims?
Claims are the key-value pairs in a JWT's payload. Registered claims defined by RFC 7519 include iss (issuer), sub (subject), aud (audience), exp (expiration), iat (issued at), nbf (not before), and jti (JWT ID). Applications can add any custom claims they need.
Why are there three parts in a JWT?
The three parts serve distinct roles: the header specifies the algorithm and token type, the payload carries the claims (the actual data), and the signature ensures the token has not been modified. This separation allows anyone to read the header and payload while the signature guarantees integrity.
Can I decode a JWT without the secret key?
Yes. The header and payload are Base64URL-encoded, not encrypted. Anyone can decode them — that is exactly what this tool does. The secret key is only needed to verify the signature, which proves the token was issued by a trusted party. Never put sensitive data in a JWT unless you use JWE encryption.
What does 'exp' mean in a JWT?
The exp (expiration time) claim is a Unix timestamp identifying when the token expires. After this time, the token must not be accepted. For example, an exp of 1700000000 corresponds to November 14, 2023 at 22:13:20 UTC. This tool shows a live countdown when an exp claim is present.
Is it safe to store JWTs in localStorage?
Storing JWTs in localStorage is convenient but risky. Any JavaScript on the page — including third-party scripts and XSS payloads — can access localStorage. A safer approach is to store JWTs in HttpOnly, Secure, SameSite cookies that JavaScript cannot read. If you must use localStorage, ensure strong XSS protections are in place.