Sponsored placement
What Is a JSON Web Token (JWT)?
A JSON Web Token (JWT) is a compact, URL-safe string used to transmit claims between two parties. It is the most common format for API authentication tokens and session management in modern web applications. When you log in to a SaaS product, the server typically returns a JWT that your client sends in the Authorization header of every subsequent request.
A JWT consists of three Base64url-encoded sections separated by dots: the header, the payload, and the signature. The header specifies the token type and signing algorithm. The payload contains the claims — structured data such as user ID, email, roles, token expiry (exp), and issue time (iat). The signature is a cryptographic hash that proves the token has not been tampered with.
Because the header and payload are only encoded, not encrypted, anyone who holds the token can read the claims inside. The signature ensures the claims have not been modified, but the data itself is visible. This is why JWTs should not contain sensitive information like passwords, and should always be transmitted over HTTPS.
- Header: token type (JWT) and signing algorithm (HS256, RS256, etc.)
- Payload: claims — sub (user ID), exp (expiry), iat (issued at), roles, email
- Signature: cryptographic proof the token was not tampered with
- Encoding: Base64url (not encryption — anyone can decode the payload)
- Transmission: always use HTTPS, never put JWTs in URLs
How to Use This JWT Decoder
Paste the full JWT string (including all three dot-separated parts) into the input. Click Decode and the tool instantly shows the header and payload in formatted, readable JSON. It also highlights the expiration time (exp claim) in human-readable form if present.
This tool only decodes — it does not verify the signature. Signature verification requires the secret key or public key, which you should never share in a client-side tool. For production token verification, always use a server-side JWT library.
Common JWT Claims Explained
The JWT specification defines several registered claim names. Understanding what each means helps you debug authentication issues faster. The sub (subject) claim identifies the user or entity the token refers to. The exp (expiration time) claim sets a Unix timestamp after which the token is no longer valid. The iat (issued at) claim records when the token was created. The nbf (not before) claim sets a time before which the token should not be accepted.
Application-specific custom claims carry business logic: user roles, plan tier, tenant ID, and feature flags are all commonly stored in JWT payloads. Custom claims help APIs avoid a database lookup on every request by encoding the necessary authorization data directly in the token.
- sub: subject — the user ID this token represents
- exp: expiration — Unix timestamp when the token becomes invalid
- iat: issued at — Unix timestamp when the token was created
- nbf: not before — token should not be accepted before this time
- iss: issuer — the server or service that created the token
- aud: audience — the intended recipient of the token
Why marketers use this tool
- Inspect JWT header and payload without writing code
- Check expiration and issued-at timestamps at a glance
- Debug API auth issues faster by seeing raw claims in readable JSON
Frequently Asked Questions
What does a JWT decoder do?
A JWT decoder splits a JSON Web Token into its three parts and decodes the Base64url-encoded header and payload into readable JSON. It shows you the claims inside the token — user ID, expiry time, roles, and any custom fields — without requiring code or a terminal.
Is it safe to paste my JWT into this decoder?
This tool runs entirely in the browser — no data is sent to any server. However, JWTs are credentials. Treat a JWT like a password: avoid pasting production tokens into any online tool. For debugging, use test tokens or tokens with short expiry times in non-production environments.
Does this tool verify the JWT signature?
No. Signature verification requires the secret key (for HMAC algorithms like HS256) or the public key (for RSA algorithms like RS256). These should never be shared with a client-side tool. This decoder only reads the header and payload claims. Verify signatures server-side using a JWT library.
Why does my JWT payload show numbers for exp and iat?
The exp and iat claims store Unix timestamps — the number of seconds since January 1, 1970. The decoder converts these to human-readable dates. An exp value of 1735689600 means the token expires at midnight UTC on January 1, 2025.
What is the difference between JWT and a session cookie?
A session cookie stores an opaque ID that the server uses to look up session data in a database on every request. A JWT encodes the session data directly in the token, so the server can verify it without a database lookup by checking the cryptographic signature. JWTs are stateless and scale better; session cookies require centralized storage but are easier to invalidate immediately.