What does a JWT decoder do?
A JWT in the compact JWS format supported here has three dot-separated parts: header, payload and signature. The first two are base64url-encoded JSON; this tool turns them into bytes, strict UTF-8 and then a JSON object, so you can read the header, the payload, the raw signature segment and the time claims.
Decoding is not verifying. Base64url is not encryption, so anyone holding the token can read it. This tool only reads: it does not check the signature, asks for no key and produces no signature.
How to use it
- Paste the token into the input box. A leading
Bearerprefix is removed with a warning. - Read the header and payload.
algandtypare the token's own claims, not a trust result. - Choose the time zone for the times, or turn off evaluation against your device clock.
- Copy the payload or header. Clear removes the token, results and everything on screen.
- Example builds a synthetic token with a random signature; it belongs to no real user.
Why is the signature never verified?
Verifying a signature needs a trusted key and a verification policy. This tool accepts no key and performs no signature check, so every result carries the warning Signature not verified. The server accepting the token must make its own access decision.
algis a header claim that whoever made the token can write; the tool only displays it.alg: noneclaims the token is unsigned. The tool reads it but produces no trust result.- Even a correctly signed token is not counted as verified here; there is no key input.
- Do not read a result as a valid session. Issuer, audience, expiry and signature checks are the server's job.
How exp, nbf and iat are read
RFC 7519 defines these claims as NumericDate: seconds since 1970-01-01T00:00:00Z, ignoring leap seconds, with non-integer values allowed. The tool checks a value's type and range before making a date, and never shows an invalid one.
| Claim | Meaning (RFC 7519) | Rule in this tool |
|---|---|---|
exp | The current time must be before this time | Expired when now is equal to or greater than exp |
nbf | The current time must be equal to or after this time | Not yet valid when now is less than nbf |
iat | The time the token was issued | Only displayed; a warning if it is ahead of your device clock |
A missing claim stays unknown. A value that is not a number, is infinite or lies outside the safe integer range gets a warning and is not evaluated. The same epoch shows different clock times in different time zones, so the tool shows your chosen zone with the UTC ISO form. Evaluation against your device clock does not replace server-side verification.
Errors and what is not supported
- Any segment count other than three (1, 2 or 4) is an error.
- Five segments mean an encrypted JWE; only signed three-segment JWS is read.
- An empty payload segment (
header..signature) is a detached payload, which is not supported. +,/,=or a space are invalid in base64url and are reported with their position.- Invalid UTF-8, invalid JSON or JSON that is not an object is an error; a payload cannot be an array or string.
- JSON nested deeper than 64 levels is not shown.
Synthetic example
The token below is a synthetic example made for this page; it belongs to no real user and its signature segment is meaningless text.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJkZW1vLXVzZXIiLCJleHAiOjE3OTMwOTE2MDB9.c2lnbmF0dXJlLWRlbW8Decoded, the header has alg: HS256, and the payload has sub: demo-user and exp: 1793091600, which is 27 October 2026 09:00:00 UTC. The signature is still not verified.
Privacy, limits and sources
- A token can be up to 32 KiB and JSON is shown up to 64 levels deep; these are design limits of this tool.
- The token is never written to a share link, the address bar, localStorage or sessionStorage, and never sent in a network request. A link can only carry the time zone and evaluation settings.
- A real unexpired token can grant access; avoid pasting production tokens into any online tool.
- The technical details were checked on 25 October 2026 against RFC 7519 and RFC 7515.
To inspect segments one by one there is the Base64 converter, to format a payload the JSON formatter, and to convert epoch values the Unix timestamp converter.
Frequently asked questions
What is the difference between decoding and verifying a JWT?
Decoding turns the base64url segments into readable JSON and needs no key. Verifying checks on the server that the signature matches the right key and that expiry, issuer and audience fit expectations. This tool only decodes.
Why does every result say Signature not verified?
Verification needs a key and the tool has no key input. The warning always shows so a result is never read as a valid token, even for a correctly signed one.
What does alg none mean?
alg is a header claim; none says the token is unsigned. The tool shows it and warns but produces no trust result. An unsigned token proves no identity.
Is a token expired when exp equals the current time?
Yes. RFC 7519 requires the current time to be before exp, so equality means expired. For nbf the current time must be equal to or after it. The decision uses your device clock.
Is my token sent anywhere?
No. Decoding runs in your browser; the token is not sent, stored or added to a share link.
Can I decode a JWE or a token with a detached payload?
No. A five-segment JWE and a token with an empty middle segment (header..signature) get a clear error; only three-segment compact JWS is read.