Guide update, 14 October 2026: the built-in Sample does not contain the one-hour dates previously used in this guide. The walkthrough below shows its actual values; the separate one-hour calculation remains an arithmetic example, not the Sample button’s output.
Your server returns a 401 Unauthorized. Did the token expire, or is the scope wrong? The exp claim in a sample token helps explain expiry, but it cannot prove why a request was rejected. Start with a sample or test token rather than pasting a live credential into a website.
A signed JWT payload is encoded, not encrypted
The common signed JWT format covered here has three parts joined by dots: header.payload.signature. The header and payload are base64url-encoded; an encrypted JWT can have a different structure.
This is where a common misconception starts. base64url is encoding, not encryption, so anyone can reverse it and read the contents without a key. The user ID and roles inside the payload are visible to anyone holding the token. That is exactly why you must never put secrets like passwords in the payload.
Reading the claims inside the payload
Each field inside the payload is called a claim. RFC 7519 defines a set of registered claims, so once you know the names, the meaning reads straight off.
| Claim | Meaning |
|---|---|
iss | Issuer |
sub | Subject (usually the user ID) |
aud | Audience |
exp | Expiration time |
iat | Issued at |
nbf | Not valid before |
jti | Unique token ID |
The three time claims, exp, iat, and nbf, are the ones you reach for most often when debugging.
Checking expiry: exp is a Unix epoch
exp is the expiry, but its value looks like 1700003600. It was never meant to be read by a human: it is a Unix epoch, the number of seconds since 1970.
These values are seconds, not milliseconds (RFC 7519, NumericDate). As a separate arithmetic example, not the built-in Sample, iat: 1700000000 becomes 2023-11-14T22:13:20Z and exp: 1700003600 becomes 2023-11-14T23:13:20Z. Subtracting them gives 3,600 seconds: one claimed hour, not proof that a credential was usable for an hour.
Repeat the built-in Sample check
- Open the English JWT decoder and press Sample, not Paste. You do not need a token from your account or server.
- Under Payload, compare these exact fields:
{
"sub": "1234567890",
"name": "PiPi Worlds",
"iat": 1718500000,
"exp": 1900000000
}
- Compare the displayed time claims.
iatreads 16 June 2024, 01:06:40 UTC;expreads 17 March 2030, 17:46:40 UTC. The tool prints ISO timestamps with a.000Zending;Zmeans UTC, not your local time zone. The claimed interval is 181,500,000 seconds, not one hour. It is demonstration data, not a recommended token lifetime. - Keep reading the Unverified notice even if the badge says Before stated expiry. At the review on 14 October 2026 that badge was expected; at or after the displayed expiry it should instead say At or past stated expiry. Neither label is a signature or permission check.
The As of input timestamp matters: this tool evaluates the badge when its input changes. It is not a live countdown and does not promise to flip while an unchanged token sits on the screen. To make a fresh comparison, use Clear, then Sample, and read the new timestamp. Your device clock is part of that comparison; a server may apply its own validation rules and permitted clock skew.
This sample has no iss, aud or nbf. Their absence is not a successful issuer, audience or not-before check. The decoder has no expected issuer, audience or trusted verification key to compare against. Required claims depend on the receiving application; consult its validation rules rather than treating a readable payload as acceptance. Do not send this public demonstration token to an API to test whether it works.
If your incident still returns 401, this exercise has only shown how to read claims. Use the server’s validation result and your approved local debugging workflow to investigate the actual rejection; do not replace the sample with a live bearer token here.
Decoding is not verifying
This is the distinction that matters most. Reading a token’s contents and confirming the token is genuine are two different things.
The third part, the signature, is a value the issuer created with a signing key. Confirming it has not been tampered with requires verifying that signature with the issuer’s algorithm and a trusted secret or public key (RFC 7515). This decoder never receives or stores a key, so it does not verify anything. Treat the payload you can see as untrusted until your server checks the signature. Even if the payload says role: admin, believing that without verification is how privilege bugs happen.
Where are you pasting that production token?
Do not paste a production access token into an online decoder while debugging a 401. A bearer token is a credential that anyone who obtains it may be able to use (RFC 6750).
The PiPi Worlds JWT decoder performs its decoding in your browser, but it does not certify that a live credential is safe to paste into a website. Use its sample or a test token to learn the structure. For a production incident, follow your organization’s approved local debugging process and check the server’s validation result. You can use the JSON formatter on test payloads and the Base64 tool to explore sample encoding.