Read JWT header and claims with the right trust boundary
The JWT Decoder makes the header and payload of a JSON Web Token readable. It helps inspect declared claims during debugging.
When should you use it?
- Check an exp or iss claim in a development token.
- Read header metadata such as alg and kid.
- Diagnose why an application sees a different claim value.
Example: read an unverified claim
This example has a placeholder signature. The decoder displays claims, but only a separate trusted verifier can establish token authenticity or authorization.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMiLCJyb2xlIjoicmVhZGVyIn0.c2lnverification: NOT VERIFIED
payload.sub: "123"
payload.role: "reader"Decode the token before interpreting its fields
A common signed JWT has three dot-separated segments: an encoded header, encoded claims, and a signature. Decoding the first two reveals the text they contain. It does not establish who created the token or whether either segment was changed. Treat every displayed claim as untrusted until the application verifies the token using its expected signing configuration.
Check times and audience in the verifying application
Claims such as exp and iat commonly use seconds since the Unix epoch, while many JavaScript date APIs expect milliseconds. Also check the expected issuer and audience in the actual verifier. A decoded role or admin flag is not authorization evidence. Use a synthetic or redacted token when preparing a report, because a live bearer token can grant access even though its payload is readable without a key.
Inspect a token without sending it away.
Read the JSON header and payload of a three-part JWT. Numeric iat, nbf, and exp claims are shown as UTC timestamps with an interpretation based on this device’s clock.
Paste a three-part token
Header, payload, and signature are separated by dots.
Decode locally
Base64url segments are decoded as UTF-8 JSON.
Inspect unverified claims
Review header, payload, and time claims without treating them as trusted.
How can I read JWT exp and iss claims without trusting the token?
Paste a three-part compact JWT into Decoder. It base64url-decodes the header and payload and presents the claims; numeric exp, nbf, and iat claims receive a UTC interpretation. This is useful for debugging the text of a token, not for deciding whether to accept it.
JavaScript: claims are untrusted until verified
javascriptconst parts = token.split('.');
// Decoding parts[1] lets you inspect claims.
// Authorization still requires trusted signature and claim checks.The page performs decoding only. It does not possess the issuer’s verification key or check audience, issuer, signature, or authorization rules.
Does a future exp value prove a JWT is valid?
No. Anyone can write an encoded payload with a future timestamp. A trusted verifier must check the signature and the application’s required claims before using it.
What should you check before using the result?
Decoding is not signature verification. Treat claims as untrusted input; this page cannot establish token authenticity, authorization, or whether an algorithm is acceptable.
What is not verified
This decoder does not validate the signature, signing algorithm, issuer, audience, token revocation, or authorization rules. A future expiration time does not make a token trustworthy. Verify tokens in the application responsible for accepting them.
Supported token format
Three-segment compact tokens with JSON object headers and payloads are supported. Encrypted five-part JWE tokens are not decoded. Malformed base64url, invalid UTF-8, and invalid JSON produce an error. Tokens are retained only in tab memory and never placed in URLs or localStorage.
Technical reference: JWT structure and registered claims · RFC 7519