JWT Decoder

Built & maintained by the MatrixInn Solutions engineering team · Last reviewed June 2026

How to decode a JWT online

Paste your JSON Web Token (the header.payload.signature string) into the box above.
Click Decode token to base64url-decode and pretty-print the header and payload as JSON.
Read the human-readable exp, iat and nbf times below, then use Copy payload to grab the claims.

Decoding starts the moment you stop typing, so you rarely need to press the button at all — paste a token and the header and payload appear side by side. If you do not have a token handy, click Load sample to drop in a valid example and see exactly how the output is laid out.

Why use a JWT decoder?

JSON Web Tokens pack authentication claims into a compact, base64url-encoded string that is impossible to read at a glance. A JWT decoder unpacks the header and payload so you can inspect the algorithm, subject, scopes, issuer, and audience while debugging logins, API gateways, or OAuth flows. Crucially, decoding is not verification: anyone can read a JWT, so this parser deliberately skips the signature check and never asks for your secret. Because it runs entirely in your browser, even tokens carrying personal data or access scopes stay on your machine — nothing is uploaded, logged, or stored anywhere.

Anatomy of a JSON Web Token

Every JWT is three base64url-encoded segments joined by dots: header.payload.signature. The header names the signing algorithm (alg, e.g. HS256 or RS256) and token type (typ). The payload carries the claims — the actual data about the user or session. The signature is computed over the first two segments with a secret or private key; it is what makes a token tamper-evident, and it is the part this tool never checks. Note that the payload is only encoded, not encrypted, so any claim you place in a JWT is readable by anyone who holds the token.

Claim	Name	What it means
`iss`	Issuer	Who created and signed the token
`sub`	Subject	The user or entity the token is about
`aud`	Audience	The intended recipient(s) of the token
`exp`	Expiry	Unix time after which the token is invalid
`nbf`	Not before	Unix time before which the token is not yet valid
`iat`	Issued at	Unix time the token was created
`jti`	JWT ID	Unique identifier, useful for revocation lists

Common use cases

Debugging logins — confirm the right sub, roles or scopes are present after an auth flow returns an unexpected token.
Diagnosing 401/403 errors — check whether exp has passed or nbf has not yet been reached before blaming your API.
Inspecting OAuth and OIDC ID tokens — read the aud and iss to verify a token came from the provider you expect.
Reviewing third-party API keys — many services issue JWT-shaped keys; decode one to see its embedded permissions.
Teaching and code review — show colleagues exactly what a token exposes, and why secrets should never live inside a payload.

Tips & gotchas

JWT segments use base64url, not standard Base64 — - and _ replace + and /, and padding is dropped. This decoder restores them automatically.
Timestamps (exp, iat, nbf) are seconds since the Unix epoch, not milliseconds. A token that looks like it expires in the year 55000 usually has millisecond values by mistake.
An alg of none means the token is unsigned — a known attack vector. Never accept it in production.
Decoding always works without a key; verification never does. If a token decodes cleanly it tells you nothing about whether the signature is valid.
Watch for stray whitespace or a wrapping Bearer prefix when copying from logs or headers — strip them before decoding.

Frequently asked questions

Is this JWT decoder free and private?

Yes — it is 100% free with no sign-up, and completely private. Your token is split and base64url-decoded directly in your browser; nothing is ever uploaded to a server, so even tokens containing sensitive claims stay on your machine.

Does it verify the JWT signature?

No. This tool only decodes the header and payload so you can read the claims. It does not check the signature, because that requires your secret or public key. Never trust a token in production without verifying its signature server-side.

Can it read the expiry and issued-at times?

Yes. If your payload contains exp, iat or nbf, the decoder shows each as a human-readable date and time alongside the raw Unix timestamp, and flags whether the token has already expired.

Why am I getting a decode error?

A JWT must have three dot-separated parts (header.payload.signature) and each must be valid base64url that decodes to JSON. If you paste a truncated, malformed, or non-JWT string, you will see a friendly error explaining what went wrong.

What do the standard JWT claims mean?

The registered claims defined by RFC 7519 are iss (issuer), sub (subject), aud (audience), exp (expiry), nbf (not before), iat (issued at) and jti (token ID). Everything else in the payload is a public or private claim added by the issuer, such as name, email, roles or scopes.

Is it safe to paste a real, live token here?

Decoding happens entirely in your browser, so the token text is never transmitted, logged or stored — it is as safe as opening it in your own dev tools. That said, a valid token is a live credential: treat the screen like a password field, and revoke or rotate the token if anyone else could have seen it.