JWT Decoder
Paste a JSON Web Token to decode its header and payload. This only decodes — it does not verify the signature.
Header
{
"alg": "HS256",
"typ": "JWT"
}Payload
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1736936800,
"exp": 1768472800
}iat: 1/15/2025, 10:26:40 AM
exp: 1/15/2026, 10:26:40 AM — expired
How to use this tool
Paste the token. It can come straight from an Authorization: Bearer … header, with quotes from a JSON response, or wrapped across lines in a log: the "Bearer" prefix, the quotes and the line breaks are removed before decoding. The header and payload appear as formatted JSON, and exp, iat and nbf are shown as dates as well as numbers.
What the notes next to the dates mean
- expired or not expired yet:
expcompared with your device's clock. A server compares with its own clock and may allow a minute or two of leeway, so a token that expired seconds ago can still be accepted, or rejected a little early. - not valid yet:
nbfis in the future, so a server should refuse the token until then. - looks like milliseconds: the number is above 100,000,000,000. JWT times are seconds since 1 January 1970; a value such as 1790000000000 comes from code that used
Date.now()without dividing by 1000, and it points to a date tens of thousands of years ahead, so the token would effectively never expire.
When it won't decode
- "must have three parts": the token was cut off when copied, or it isn't a JWT. Opaque access tokens from some providers are just random strings.
- "five parts": an encrypted JWT (JWE). Only a holder of the key can read it; this is by design.
- "isn't valid Base64URL" or "not to JSON": the message names the header or the payload, usually because characters were lost in copying.
A token whose header says "alg": "none" decodes normally here, but it carries no signature, and a server must never accept it. The JWT guide walks through a token part by part and explains why decoding is not the same as verifying.
Frequently Asked Questions
Is it safe to paste a real production JWT into this tool?
Decoding happens entirely in your browser and the token is never sent anywhere, so it's technically safe from a network standpoint. That said, a JWT's payload is only Base64-encoded, not encrypted, so anyone who has the token can already read its contents — treat production tokens (especially ones that haven't expired) with the same care as a password and avoid pasting them into tools you don't trust.
Why doesn't this tool verify the signature?
Verifying a signature requires the secret key (for HMAC algorithms like HS256) or the public key (for RSA/ECDSA algorithms), which only the issuing server should have — a client-side tool has no legitimate way to obtain it. This tool only decodes the header and payload to let you inspect the claims; it doesn't tell you whether the token is authentic.
The token decodes fine, so why does my API reject it?
Decoding only shows what the token says. The API also checks the signature, the expiry against its own clock, and usually the issuer (iss) and audience (aud) claims. Compare aud and iss with what the API expects: a token issued for one application or environment is often sent to another by mistake.
Related Tools
Related Blog Posts
What Is a JWT and How to Decode One Safely
A real token taken apart segment by segment: Base64URL and its missing padding, what exp and iat say in plain dates, why a 5-part token won't decode, and what a decoder can't tell you.
Read moreHow to Use QR Codes for Marketing, Docs, and Events
How much a QR code can hold, why a shorter or uppercase link gives a code that scans more easily, what error correction actually protects against, and how to size one for print.
Read moreHEX, RGB and HSL: How the Conversions Work and Where They Round
#4F46E5 converted to RGB and HSL step by step, why 89.4% of all colours change when copied as whole-number HSL, why HSL lightness is not brightness (yellow and blue at 50% differ eightfold in contrast), and the alpha that hex can't write exactly.
Read more