JWT Decoder

What is a JWT decoder?

A JWT decoder takes a JSON Web Token — a long string of three dot-separated parts — and turns it back into the readable JSON it carries. Paste a token and you instantly see its header, its payload (the claims), the signing algorithm, and whether it has expired. It's the fastest way to answer questions like "why is this request being rejected?", "what role is encoded in this token?", or "when does this session run out?"

Crucially, this decoder runs 100% in your browser. The token is parsed locally with the platform's own atob and TextDecoder APIs — nothing is sent to a server, nothing is logged, nothing is stored. That matters more than it sounds, and we'll come back to why.

How to use it

1. Paste your token into the box (or click Sample to try one).
2. The tool splits it on the dots and base64url-decodes the first two parts.
3. Read the header and payload as pretty-printed JSON in their own panels.
4. Check the badge — Valid or Expired — and the humanized exp, iat and nbf dates.
5. Hit Copy on any panel to grab the decoded JSON.

If the input is malformed — wrong number of parts, or a segment that isn't valid base64url JSON — you'll get a clear, specific error instead of a silent blank.

How a JWT is structured

A JWT is three base64url-encoded strings joined by dots:

header.payload.signature

• Header — usually { "alg": "HS256", "typ": "JWT" }. It names the signing algorithm so the verifier knows how to check the signature.
• Payload — the claims: the actual data, like sub (subject/user id), name, role, and the time claims exp, iat, nbf.
• Signature — a cryptographic stamp over the header and payload, created with a secret (for HMAC like HS256) or a private key (for RSA/ECDSA like RS256). It proves the token wasn't altered.

Each part is base64url, a URL-safe variant of base64 that swaps +// for -/_ and drops padding so the token survives being placed in URLs and headers. Decoding simply reverses that encoding — which is why anyone can read a JWT's contents.

Common claims, decoded

The payload carries registered claims defined by the spec plus any custom ones your app adds:

• sub — the subject, typically the user ID.
• exp — expiration time (Unix seconds). After this, the token should be rejected.
• iat — issued-at time.
• nbf — not-before time; the token is invalid until then.
• iss / aud — the issuer and intended audience.

This tool detects exp, iat and nbf, converts each Unix timestamp to a readable UTC date plus a relative description ("in 58 minutes", "3 days ago"), and uses exp to show the Valid / Expired badge. The rest of the claims are shown verbatim in the payload panel.

Decoding is not verifying — and why that matters

This is the single most important thing to understand: decoding a JWT does not prove it's genuine. The header and payload are only encoded, not encrypted, so reading them is trivial. The signature is what makes a token trustworthy — but verifying it requires the secret (HMAC) or the public key (RSA/ECDSA), and it has to happen somewhere you trust. If you want to understand the hashing underneath, the hash generator lets you compute the same SHA digests that HMAC signatures are built on.

That's why this tool deliberately shows the signature without verifying it, and why you should be deeply suspicious of any site that offers to "verify" your token by asking you to paste your secret into a web form.

The privacy wedge: your token never leaves your browser

A JWT is a live credential. While it's valid, it can often be replayed to impersonate the user it represents. So pasting a real token into a tool that processes it server-side means handing a working credential to a third party — where it can be logged, cached, or leaked.

This isn't hypothetical. The most popular online JWT inspector, jwt.io, is operated as lead-generation for a commercial identity vendor (Auth0/Okta), and in November 2025 a wave of server-side "JWT formatter" and token-debugger sites were caught logging pasted tokens and secrets — turning a debugging convenience into a credential breach. Once a secret leaks, every token your service ever signed with it is forgeable.

Pageonaut's decoder sidesteps the whole risk class: the parsing is plain JavaScript running on your machine. The token is never transmitted, so there's no server log to leak, no funnel to sign up for, and no secret to harvest. Open your network tab and you'll see exactly zero requests when you decode. If you're handling a real production token, that local-only guarantee isn't a nicety — it's the responsible default.

Tips

• Never store secrets in a payload. It's readable by anyone holding the token.
• Watch the clock. A token that "doesn't work" is very often just expired — check the exp badge first.
• Mind nbf. A token can be perfectly valid yet rejected because it isn't active yet.
• Verify on your server. Use a maintained library (with the correct algorithm pinned) to validate signatures — never trust a token just because it decoded cleanly.

Paste, read, copy — and keep your credentials on your own device where they belong.