JWT Decoder
Paste a JWT or Bearer token to read its claims and live expiry timing without sending or saving the token.
- Fewer clicks, keyboard friendly
Press / to focus the token field.
Token overview
Paste a JWT to inspect its header, claims, and time values.
This reads token data only; it does not verify a signature, issuer, audience, or permissions.
How to use
- Paste a compact JWT or an Authorization value beginning with Bearer into the token field.
- Read the decoded header and payload immediately; Copy copies either JSON object without changing the token.
- Check exp, iat, and nbf in the Time claims panel for the Unix seconds value, your device time, UTC, and a live relative time.
- Treat the result as inspection only: verify the signature, issuer, audience, and permissions in your application or identity provider.
What this decoder reads
A common signed JWT uses JWS Compact Serialization: three Base64URL parts joined with two dots (`header.payload.signature`). The header and payload are encoded JSON, so this tool can show them without a secret. The third part is the signature; it is intentionally not decoded as JSON and is never treated as proof that a token is genuine. A five-part value is a JWE (encrypted JWT), whose claims need a recipient key and cannot be read by this decoder.
This parser accepts the unpadded Base64URL alphabet used by JWS and rejects ordinary padding (`=`), invalid bytes, non-JSON values, and arrays where a JWT object is required. It also accepts a pasted `Bearer ` prefix from an HTTP Authorization header.
How JWT time claims work
RFC 7519 defines `exp` (expiration), `nbf` (not before), and `iat` (issued at) as NumericDate values: seconds since 1970-01-01T00:00:00Z, ignoring leap seconds. `exp` is an exclusive boundary: at the exact `exp` second, this tool marks the token expired. `nbf` becomes usable at its exact second.
The Time claims panel keeps the relative display current and also shows an exact device-local time plus UTC, so a timezone or clock mismatch is visible instead of being hidden behind a vague date. A string such as `"exp": "1704067200"` is not a valid NumericDate and is called out rather than silently converted.
Decoding is not authentication
Base64URL encoding is reversible; it is not encryption. Anyone holding a normal signed JWT can read its header and claims. Conversely, a readable token can be forged or have the wrong issuer, audience, algorithm, or signature. Use this page to troubleshoot token shape and timestamps, then have the service that accepts the token verify it with its trusted key and validation rules.
The token stays in this page while you inspect it. It is not stored in browser storage, so refreshing or closing the page removes it from this tool.
Frequently asked questions
Can I decode a JWT without the secret?
Yes. A three-part signed JWT exposes its header and payload as Base64URL-encoded JSON, so decoding does not need a secret. The secret or public key is required to verify the third signature part and decide whether claims can be trusted.
What does exp mean in a JWT?
`exp` is the expiration NumericDate in seconds since the Unix epoch (1970-01-01T00:00:00Z). RFC 7519 says a current time equal to or later than `exp` must be rejected, so the exact exp second is already expired.
What are iat and nbf in a JWT?
`iat` records when a JWT was issued, while `nbf` is the earliest Unix-second time at which it may be accepted. Both use the same NumericDate seconds format as `exp`; neither one by itself proves the JWT is authentic.
Why can’t this decoder read a five-part token?
A compact JWE has five dot-separated parts and encrypts its claims. Reading it requires the recipient’s decryption key, whereas this decoder only reads the two visible JSON parts of a three-part JWS.
Does decoding prove that a JWT is valid?
No. Decoding only proves that the first two parts can be read as JSON. A valid authentication decision also verifies the signature, expected issuer and audience, time claims, and any application-specific permissions.
Related tools
Updated 2026-10-15