JWT Decoder

Overview

Read what's inside a JSON Web Token — without sending it anywhere

A JWT decoder splits a JSON Web Token into its three dot-separated parts and base64url-decodes the header and payload so you can read the claims. A JWT is encoded, not encrypted — anyone holding it can read it. Decoding is not verifying: this tool runs entirely in your browser and does not check signatures.

A JSON Web Token is three base64url-encoded strings joined by dots: a header saying which algorithm signed it, a payload holding the claims, and a signature. A JWT decoder reverses the first two so you can actually read them. Paste a token here and it decodes as you type — no button to press, no upload, no account.

Two things about JWTs surprise people, and both matter more than any feature list. The first: a JWT is encoded, not encrypted. Base64url is a transport format, not a lock. Anyone who gets hold of your token — in a log file, a browser extension, a screenshot — can read every claim in it without a key or a secret. That is by design, and it is why user emails, roles, tenant IDs, and internal flags should be treated as public the moment they go into a payload.

The second: decoding a token is not verifying it. This tool reads what a token claims; it cannot tell you whether those claims are true. Confirming a token is authentic means checking the signature against the signing secret or public key, and that key is not something you should ever paste into a web page. So this decoder deliberately doesn't ask for one, and it doesn't verify. The Signature view shows you the raw third segment and says so plainly.

What it does do is fast and useful: four readings of the same token. Claims lists every claim in it, with exp, iat and nbf as real dates in your own time zone, a relative reading like "expired 3 days ago" beside each, and a status of Valid, Expired, Not yet valid or No Expiry. Header and Payload give you the decoded JSON. Signature gives you the raw third segment and its length in bytes. And it says when something is structurally wrong: alg: none is flagged as unsigned, a timestamp written in milliseconds is named rather than read as the year 58665, and a signature that is not the length its algorithm produces is called out.

And it stays on your machine. Everything happens in your browser's JavaScript — the token is never transmitted, and the page keeps working offline. Related: Base64 Encoder/Decoder, Unix Timestamp Converter.

Testing login in a UI suite? The Auth Flows page on QA Playground, our free automation practice site, has a two-step login and a session that expires mid-task for your script to handle.

Use cases

When a JWT decoder helps

Debugging auth. See which claims your identity provider is actually issuing.
Checking expiry. Find out whether a 401 is an expired token or something else.
Reading someone else's token format. Compare what two services put in a payload.
Spotting oversharing. Notice PII or internal IDs that shouldn't be in a payload at all.
Catching alg: none. See immediately when a token carries no integrity protection.
Sensitive tokens. Inspect a token without it leaving your device — or, better, use a throwaway one.

Guide

How to decode a JWT

Paste the token

Drop the full JWT into the box. It decodes live as you type — there's no Decode button, and nothing is uploaded.

Read the header

The Header view shows the decoded header JSON: the signing algorithm (alg), usually the type (typ), and a kid if the issuer names which key it used. Anything odd in there — no alg at all, an enc that belongs to an encrypted token — is called out above the claims.

The decoder with RFC 7515’s unsecured token pasted. The verdict reads Expired beside a tag reading none, and a red note under it reads: alg is none, this token is UNSIGNED. Nothing protects it from being rewritten, and a server that accepts it can be forged against. The segment map shows the signature as empty, 0 chars, and the status line reads alg none, signature 0 bytes. — RFC 7515’s own unsecured token. `alg: none` is not an algorithm — it means nothing signed this, and the tool says so before it says anything else.

Read the payload

The Payload view shows the decoded payload JSON, and Claims lists the same thing claim by claim — sub, iss, aud, exp, and any custom fields your service added, each tagged as registered or custom.

Read the claims

Status, exp, iat and nbf are pulled out as real dates with a relative reading beside each one, and the algorithm sits next to the status. Anything structurally wrong with the token is listed above them — an unsigned alg, a timestamp written in milliseconds, a signature whose length does not fit the algorithm.

The decoder with the example token from RFC 7519 pasted. The verdict reads Expired with HS256 and typ JWT tags and the line: exp passed 15 years ago. The exp claim card below shows the raw value 1300819380 on the right, the date 23 Mar 2011, 00:13:00 in the Asia/Calcutta zone, and the words 15 years ago under it. — The example token published in RFC 7519, read against this machine’s clock. The raw `exp` stays beside the date it means.

Copy or clear

Copy hands over whatever the current view is showing: the claim list as text, either JSON block, or the raw signature segment. Clear empties the box. To confirm the token is genuine, verify the signature in your own code — not here.

The decoder on a phone with the Decoded tab open. The four view buttons sit on one row above Sample token and Clear, and the claims list shows a Valid verdict with HS256, typ JWT and kid tags. — On a phone the token and the reading become tabs, and the four views stay on the bar.

Realistic example

Paste a token whose payload is {"sub":"1234567890","name":"John Doe","iat":1516239022} and you'll see the claims formatted, with Issued At rendered as a real date and Status showing No Expiry — because that payload has no exp claim at all, which is itself worth knowing.

Advanced tip

If Status says Valid, that means one thing only: the exp claim is in the future. It says nothing about whether the signature is good, whether the issuer is who you expect, or whether the token was revoked.

The decoder showing a token whose exp claim is 1789151075000. The verdict reads Check the dates, with the line: a time claim is not a usable timestamp, so there is no honest verdict to give. A red note under it reads that exp looks like milliseconds, that a JWT timestamp is in SECONDS, and that read as seconds it lands in 58665 while as milliseconds it is 11 Sept 2026. — A JavaScript `Date.now()` dropped straight into `exp`. Read as seconds it is the year 58665, so the tool refuses to give a verdict rather than calling the token valid for forty thousand years.

Common mistake to avoid

Don't paste a live production token into any online decoder — including this one — if you can avoid it. Use an expired or test token, or run atob(token.split('.')[1]) in your own browser console.

Good to know

What to keep in mind

This decodes, it does not verify. There is no signature verification on this page — no key input, no crypto check. A decoded token is not a trusted token.
"Valid" means "not expired". The status field compares exp to your clock and nothing else. It is not a verdict on authenticity.
Your payload is readable by anyone. Base64url is encoding, not encryption. Never put secrets in a JWT payload.
Nothing is transmitted. Decoding runs in your browser — no request carries your token, and the page works offline. Open your network tab and confirm it.
Signed tokens only. An encrypted JWT (JWE) has five segments, not three, and will be rejected. This tool can't decrypt anything.
Treat any pasted token as spent. The safest habit with any web-based decoder is to use tokens you're willing to throw away.
Free, no signup, no limits. There's no account and nothing metered.

Support

Frequently Asked Questions

What does a JWT decoder actually do?

It splits a JSON Web Token on its two dots and base64url-decodes the first two segments — the header and the payload — back into readable JSON. That's it. The header tells you the signing algorithm; the payload holds the claims. The third segment, the signature, stays encoded and is shown raw. No key or secret is needed to decode, because nothing in those first two parts is encrypted.

Is a JWT encrypted — can anyone read my token?

A standard JWT is encoded, not encrypted, so yes: anyone holding the token can read the header and payload. Base64url is a transport format, not a lock — no key required. That's why you should never put passwords, secrets, or data you wouldn't want disclosed into a payload. The signature protects against tampering, not against reading. If you need real confidentiality, you need JWE.

Does this tool verify the JWT signature?

No. This decoder reads tokens; it never verifies them. There's no key field, no secret input, and no cryptographic check anywhere on the page — the signature is displayed as raw text and nothing more. Verifying authenticity requires the signing secret or public key, which you should never paste into a web page. A decoded token is not a trusted token. Treat everything you see here as unverified claims.

Is my token uploaded anywhere, and does this work offline?

No upload, and yes it works offline. Decoding happens entirely in your browser's JavaScript — the page makes no request that carries your token, no server receives it, and nothing is stored or logged. You can verify this yourself: open your browser's network tab, paste a token, and watch that no request fires. Once the page has loaded, it keeps decoding with your connection switched off.

Is it safe to paste a production token into an online JWT decoder?

Honestly: prefer not to, with any tool including this one. A live token is a working credential, and web pages carry risk you can't fully audit — browser extensions can read what you type, and lookalike clone sites of popular decoders exist. Use an expired or test token where you can. If you must inspect a live one, run atob(token.split('.')[1]) in your own console instead.

How do I know if my JWT is expired?

The Claims view reads the exp claim, converts it from a Unix timestamp to a real date in your local time, and adds a relative reading like "expired 3 days ago" or "in 2 hours". Status then shows Expired, Valid, Not yet valid, or No Expiry if the token carries no exp at all. Note that this compares against your device clock.

What do exp, iat, and nbf mean?

They're registered claims from the JWT spec, all Unix timestamps in seconds. exp (expiration) is when the token stops being acceptable. iat (issued at) is when it was created — the gap between the two is the token's lifetime. nbf (not before) is the earliest time it may be used. This tool shows all three as dates in your own time zone with a relative reading beside each, and nbf is what puts a token in the Not yet valid state. A value that is not a whole number of seconds — milliseconds, or a string — is named rather than read.

Which algorithms does this recognise, and what does alg: none mean?

The tool shows whatever the header's alg value says — HS256, RS256, ES256 and the rest are all displayed as-is, with no whitelist and no validation against the signature. The one special case is none, which it flags as unsigned. It also measures the signature: HS256 produces 32 bytes, ES256 64, and a third segment that is not the right length for the algorithm the header declares is a real mismatch worth knowing about. That is a check on shape, not a verification. alg: none means the token has no integrity protection at all, and servers that accept it can be trivially forged against — a well-documented authentication bypass.

Why will my token not decode?

Almost always a copy-paste problem, and the message says which one. A Bearer prefix is named rather than counted as part of the token. Line breaks from wrapped log output are removed, and you are told they were. A segment that is not base64url reports the character that is not — usually a + or a / from standard base64. A segment that decodes but is not a JSON object says so, and five segments is reported as a JWE, which is encrypted and cannot be read without the key.

What's the difference between JWS and JWE — can this decode an encrypted token?

JWS is a signed token: three segments, readable by anyone, protected against tampering. JWE is an encrypted token: five segments, unreadable without the decryption key. This tool handles JWS only — it requires exactly three parts, so a JWE is rejected outright, and it has no decryption capability regardless. When people say "JWT" they almost always mean JWS.

How do I actually verify a JWT properly?

In your own code, with a maintained library — jsonwebtoken or jose in Node, PyJWT in Python, and so on. Verification means checking the signature against the expected key, pinning the algorithm explicitly so none and algorithm-confusion attacks are impossible, and then validating exp, nbf, iss, and aud. Never trust a client-side decode, and never verify by pasting your signing key into a website.

Is it free, and are there limits?

Yes, completely free — no payment, no signup, no account, no usage caps, and no watermarks. Because the decoding runs entirely in your browser, there's nothing for us to meter or rate-limit; the only practical limit is your own device on an unusually large token. Use it as much as you like, including offline once the page has loaded.

Still have questions?

If you can't find the answer you're looking for, feel free to contact our support team.

Privacy Focused

Instant Results

No Signup

Browser Based