JWT Decoder
Paste a JSON Web Token to see its header and payload as readable JSON, with standard claims explained and timestamps converted to real dates. A live status shows whether the token is valid, not yet valid or expired.
Decoded entirely in your browser — the token is never sent anywhere. Avoid pasting live production tokens into any online tool you don't trust.
Header
| algSigning algorithm | HS256 |
| typToken type | JWT |
Payload
| subSubject (user ID) | 1234567890 |
| nameName | Ayesha Khan |
| roleRole | admin |
| iatIssued at | 1758966400Sep 27, 2025, 9:46:40 AM UTC |
| expExpires at | 1916732800Sep 27, 2030, 9:46:40 AM UTC |
Signature
c2lnbmF0dXJlLW5vdC12ZXJpZmllZA
The signature is shown but not verified. Anyone can decode a JWT; only a server with the secret or public key can confirm it hasn't been tampered with.
Read what’s inside a JWT — safely
JSON Web Tokens (JWTs) carry identity and permissions between apps: after you sign in, a server hands your browser a token that proves who you are for the next requests. When authentication misbehaves — a user is logged out too soon, a role is missing, an API rejects a token — the first step is to look inside. This decoder shows a token’s header and payload as readable JSON and tells you whether it has expired, without the token ever leaving your browser.
How to decode a token
- Copy the token — often from an Authorization header (“Bearer eyJ…”), a cookie, or local storage in DevTools.
- Paste it into the box. A leading “Bearer ” is removed automatically.
- Read the status: valid, not valid yet, expired, or no expiry at all.
- Inspect the header and payload tables. Timestamps are shown as real dates with a live countdown.
- Copy either part as formatted JSON if you need it elsewhere.
The structure of a JWT
A signed JWT has three parts separated by dots: header.payload.signature. The header says which algorithm signed the token, such as HS256 or RS256. The payload holds the claims — data about the user and the token. Both are JSON encoded with Base64URL, which is why anyone can read them. The signature is calculated from the other two parts with a secret or private key, and lets the server detect any tampering.
Common claims
- iss (issuer) — who created the token, such as your auth server.
- sub (subject) — who the token is about, usually a user ID.
- aud (audience) — which service the token is meant for.
- exp (expiration) — after this time, the token must be rejected.
- nbf (not before) and iat (issued at) — when the token becomes valid and when it was created.
Time claims are Unix timestamps — seconds since 1 January 1970 UTC — so the decoder converts them to your local time.
Security notes
- Decoding isn’t verifying. This tool doesn’t check the signature; only a server with the key can confirm a token is genuine.
- JWT payloads aren’t secret. Never store passwords or sensitive personal data in them.
- Reject alg “none”. Tokens without a signature must never be accepted, and the decoder flags them.
- Handle live tokens carefully. A valid token works like a password until it expires. This tool keeps it on your device, but avoid pasting production tokens into tools you don’t trust.
Need to decode other Base64 strings? Use the Base64 Encoder/Decoder. Format the claims with the JSON Formatter, or turn an authenticated curl request into code with the cURL Converter.
Frequently asked questions
Is it safe to paste my JWT here?
The token is decoded entirely in your browser with JavaScript and is never sent to a server. Even so, treat tokens like passwords: prefer test tokens, and never paste production tokens into tools you don't trust.
Does this verify the signature?
No. Decoding only reads the header and payload, which are just Base64URL-encoded. Verifying the signature requires the secret or public key and should happen on your server.
What do exp, iat and nbf mean?
They're timestamps in seconds since 1 January 1970 (Unix time). exp is when the token expires, iat is when it was issued, and nbf is the time before which it must not be accepted.
Can anyone read the contents of a JWT?
Yes, for standard signed tokens (JWS). The signature prevents tampering, not reading. Never put secrets like passwords in a JWT payload. Encrypted tokens (JWE) are different and can't be decoded without the key.
Why is alg 'none' flagged?
A token with alg 'none' has no signature, so anyone could have created it. Servers must reject such tokens; accepting them is a well-known security vulnerability.