JWTLens

JWT Decoder

Paste a JWT — see the decoded header, payload, and whether it's expired.

JWT Token

Header

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

Payload

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

Issued at: 2018-01-18T01:30:22.000Z
Expires at: N/A
Status: Valid

What you entered

Token parts: 3

1
Split token into 3 parts
header.payload.signature= eyJhbGciOiJIUzI1NiIs…
2
Decode header (base64url → JSON)
eyJhbGciOiJIUzI1NiIsInR5cCI6Ik= {"alg":"HS256","typ":"JWT"}
3
Decode payload (base64url → JSON)
eyJzdWIiOiIxMjM0NTY3ODkwIiwibm= 3 claims
4
Check expiration
No exp claim= No expiry

Result

Status: Valid

This JWT uses the HS256 algorithm. No expiration claim is present.

Standard JWT claims and what they mean

A JWT is three base64url segments separated by dots: header, payload, and signature. These are the registered claims defined by RFC 7519, all of them optional.

Claim	Name	Meaning	Type
iss	Issuer	Who issued the token	String
sub	Subject	Who the token is about, usually a user ID	String
aud	Audience	Who the token is intended for	String or array
exp	Expiration time	Reject at or after this time	Unix seconds
nbf	Not before	Reject before this time	Unix seconds
iat	Issued at	When the token was created	Unix seconds
jti	JWT ID	Unique identifier, used to prevent replay	String

Decoding is not verifying. Anyone can read a JWT payload because it is only base64-encoded, not encrypted, so never put secrets in it and never trust its contents without checking the signature server-side. Times are Unix seconds, not milliseconds.

JWT structure

A JSON Web Token has three base64url-encoded parts separated by dots: header (algorithm and type), payload (claims like sub, iat, exp), and signature. The signature verifies the token hasn't been tampered with. JWTs are self-contained — the server doesn't need a database lookup to validate them.

Common JWT claims

Standard claims include: iss (issuer), sub (subject/user ID), aud (audience), exp (expiration timestamp), iat (issued at), nbf (not before), jti (unique token ID). Custom claims can hold any data. Never put sensitive information in a JWT payload — it's encoded, not encrypted.

Frequently asked questions

I pasted my JWT and it says 'expired' — can I still decode it?

Yes. Expiration is just a claim (the 'exp' field) inside the payload — decoding still works fine. The token's data is readable regardless of whether it's expired; expiration only matters to the server that validates it.

Is it safe to paste my JWT into this tool?

Yes — decoding happens entirely in your browser. Nothing is sent to any server. That said, a JWT's payload is not encrypted, so anyone who has the token can read its contents, which is why sensitive data should never be stored in JWT claims.

What's the difference between a JWT and a session cookie?

A session cookie is just an opaque ID — the server must look up the session data in a database. A JWT is self-contained — it carries the user data inside the token itself, which the server verifies via the signature without a database lookup.

How does decoding a JWT relate to the Base64 tool?

A JWT's header and payload are Base64url-encoded JSON. This decoder splits the token at the dots and decodes each part, which you could do manually with our Base64 tool — but this adds JWT-specific features like expiration checking and claim labeling.