Free

JWT Decoder

Header, payload and every registered claim, decoded on your machine. The token never leaves your device - verified by a test that fails if this page makes a network request.

  • Free forever
  • No signup
  • Runs in your browser

At a glance

Takes
A JWT, with or without a leading Bearer
Returns
Header, payload and every claim, with dates in your own timezone
Handles
Expiry, not-before and the alg-confusion warnings - it never verifies
Privacy
Decoded in your browser - the token is never transmitted

Nothing you type leaves this page

This tool runs entirely in your browser. Nothing you type or paste is sent to Revquix or to anyone else, no account is needed, and the page keeps working with your network disconnected.

Full detail in our privacy policy and AI policy.

How this works

About JWT Decoder

What it checks, what it deliberately does not, and how to read the output.

The token never leaves your device

Developers paste production tokens into tools like this one. Ours decodes entirely in your browser using the platform's own base64 decoder - there is no API call, no logging, no analytics event carrying the token, and the page continues to work with your network disconnected. That property is covered by a test that fails the build if this page issues any network request during a decode.

It is worth being blunt about why that matters: a JWT is a bearer credential. Pasting one into a hosted decoder hands whoever runs it a live session, and most hosted decoders do not tell you which of the two kinds they are.

What you get

The header and payload are decoded and pretty-printed, and the registered claims are resolved into something readable: `exp` and `iat` and `nbf` rendered as real timestamps in your local timezone alongside the raw epoch values, plus an at-a-glance indication of whether the token is currently within its validity window. Custom claims are shown as-is, because guessing at their meaning would be inventing information.

Decoding is not verifying

This is the single most important thing to understand about JWTs, and the most common source of real security bugs involving them. A JWT's payload is base64-encoded, not encrypted: anyone holding the token can read every claim in it, including this tool, without any key at all. Decoding tells you what the token says. It tells you nothing about whether the token is genuine.

Verification is a separate operation that requires the signing key and must happen on your server, on every request, with the algorithm pinned. If your application trusts a claim it decoded without verifying the signature, an attacker can edit that claim freely - and never let the token's own `alg` header choose the verification algorithm, because that is exactly how the `alg: none` and RS256-to-HS256 confusion attacks work.

What it will not do

It does not verify signatures, and it never will - doing so would require you to paste your signing key into a web page, which is worse advice than anything this tool could save you. It also does not decrypt JWEs, which are genuinely encrypted rather than merely encoded, and it does not tell you whether a token has been revoked, because revocation state lives in your application, not in the token.

FAQ

Questions people actually ask

The ones that come up before somebody uploads anything.

Is it safe to paste a production token here?

Into this page, yes: decoding happens locally and no network request is made, which you can confirm in your browser's network tab. As a general habit, treat any hosted JWT decoder as untrusted unless it can demonstrate that property, because a JWT is a live credential.

Does this verify the signature?

No, deliberately. Verification needs the signing key, and a tool that asks you to paste your signing key into a browser is giving you worse advice than the problem it solves. Verify on your server, with the algorithm pinned rather than read from the token.

Why can anyone read my JWT payload?

Because a JWS payload is base64url-encoded, not encrypted. Encoding is not encryption. Never put a secret in a JWT payload - the signature protects it from being modified, not from being read.

My token shows as expired but my app accepts it. Why?

Usually clock skew or a leeway window configured in your verification library, and occasionally an application that never checks `exp` at all. The second case is a bug worth finding.

Does it work offline?

Yes. Once the page has loaded it needs no network at all, which is a consequence of the same design that keeps your token local.

Next, try one of these

More from Developer, or browse the full catalogue.

Beyond the token

Auth is the part of the system nobody owns until it breaks

Session versus token, where refresh lives, what happens on rotation, and why the answer is different for a mobile client - these are design decisions, and getting them wrong is expensive in a way a decoder cannot warn you about. Book an hour with someone who has shipped it.

Talk to an engineer from ₹549/hr