JWT Decoder & Signature Verifier

Decode and optionally verify a JWT's header, payload, and signature — never transmitted.

Decoding a JWT and trusting it are two different operations, and this tool is careful to keep them separate. Pasting a token instantly reveals its header and payload — anyone can do that, since a JWT's claims are only base64url-encoded, not encrypted — while checking whether the signature was actually produced by a key you trust is a distinct, opt-in step that needs you to supply that key yourself.

How to decode and verify a JWT

Paste the token, which usually starts with eyJ, into the Token box; a two-part token with no signature decodes as well.
Read the pretty-printed header and payload, plus the badge that says how long ago the token expired or how long it has left.
Check the exp and iat rows, which turn those claims into UTC timestamps and link to the Epoch Converter; any nbf claim appears only in the payload JSON.
To check the signature, type the shared secret for HS256/384/512 (used exactly as typed, not base64-decoded) or paste a PEM or JWK public key for RS, PS or ES tokens, then click Verify signature.
For tokens from an identity provider, fetch or paste its JWKS instead; the right key is picked by the kid in the token's header.

What decoding shows you for free

A JWT is three dot-separated segments: header, payload, and signature. The header and payload are JSON, base64url-encoded rather than encrypted, so this tool decodes and pretty-prints both the moment you paste a token, with no key and no network round trip involved. A token missing its signature segment (two parts instead of three) still decodes fine, since header and payload are the two pieces that carry information.

Two time claims, exp and iat, get their own rendered row showing the UTC instant they represent, with a link across to the epoch converter if you want more detail than a single row offers. The not-before claim, nbf, has no row of its own: read it in the payload JSON and paste the number into the epoch converter yourself.

Why decoding a token proves nothing about who sent it

Anyone holding a JWT can read every claim inside it without ever knowing the signing key, because base64url is an encoding, not encryption. That means a decoded payload showing an admin role or a particular user ID is only a claim being made by whoever holds the token — it says nothing about whether that claim is genuine until the signature is checked against a key you actually trust.

The header's alg value gets flagged automatically where it matters: alg set to none means the token carries no signature at all and is trivially forgeable, and a missing alg header is treated the same way. An alg your browser doesn't recognize is flagged too, since local verification simply isn't available for it here.

Verifying the signature yourself

Local verification runs entirely through your browser's own WebCrypto implementation and supports HS256/384/512 with a shared secret you type in, RS256/384/512 and PS256/384/512 against an RSA public key, and ES256/384/512 against an elliptic-curve public key — accepted as either PEM or a raw JWK. Nothing about this step involves a network call; the cryptographic check happens locally against whatever key material you supply.

If your key comes from a JWKS endpoint, you provide that URL or paste the JSON yourself explicitly — never automatically from the token's own jku or x5u header. Those headers are attacker-controlled on a forged token, so trusting them to tell you where to fetch the verification key would defeat the point of verifying anything. A matched JWKS key also has to declare a type compatible with the token's algorithm family before verification proceeds, and a symmetric HS secret is never accepted from a JWKS at all, since a real issuer never publishes a shared secret at a public key endpoint.

What this tool doesn't do

It doesn't check issuer, audience, or expiry against your application's own trust rules — it shows you the claims and lets you judge them, but enforcing exp or aud is your backend's job, not this page's
It doesn't have any way to know your production signing key unless you type it in, so a token that verifies here only proves it matches the key material you supplied, not that it was issued by your real service
It doesn't protect against algorithm-confusion attacks beyond the JWKS type check described above — always verify against a key you obtained through a channel you trust, not one copied from the token itself
It doesn't verify EdDSA (Ed25519) or any other algorithm outside the HS, RS, PS and ES families; such tokens still decode, but their alg is flagged as unrecognized

Standard JWT claims reference

iss (issuer): who minted the token. Accept only the exact issuer strings your backend expects.
sub (subject): the user or entity the token describes. It is only unique within one issuer, so look accounts up by iss and sub together.
aud (audience): the service or services the token is meant for, as a string or an array. Reject tokens whose aud doesn't include your own identifier.
exp (expiration time): seconds since the Unix epoch after which the token must be refused, usually with a small allowance for clock skew.
nbf (not before): the earliest moment the token may be accepted; refuse it before then.
iat (issued at): when the token was created, handy for capping token age even when exp is set far in the future.
jti (JWT ID): a unique identifier for this one token. Record used values if you need to block replays or revoke a single token.

Questions people ask about JWT Decoder

Is it safe to paste a production JWT into this tool?: Decoding never leaves your browser, so pasting a token to inspect its claims is low-risk on its own. Still treat any real access token with the same caution you'd apply anywhere: avoid pasting one that's currently valid on a shared or public machine, since anyone who copies it from your clipboard or screen could technically use it until it expires.
Why does the tool say my token is valid but my server rejects it?: Signature verification here only confirms the token matches the key material you supplied — it does not check expiry, issuer, audience, or any other claim your server enforces. A signature can verify successfully against an old or unrelated key while the token is still rejected for being expired or issued for a different audience.
Can I verify a token without knowing the signing algorithm?: You don't need to guess — the algorithm is read directly from the token's own alg header and matched automatically to the right WebCrypto verification method. You still need to supply the actual key material yourself: the shared secret for HMAC algorithms, or the public key for RSA and elliptic-curve ones.
What does alg: none mean and why is it flagged?: It means the token has no cryptographic signature at all — anyone can construct one with any claims they like. It exists as a legitimate JWT value in some contexts, but a backend that accepts it is trusting the token's contents on nothing but the sender's word, which this tool flags as a serious warning rather than a routine notice.
What is a JWT and what are its three parts?: A JSON Web Token, defined in RFC 7519, is a compact, URL-safe string for passing claims between systems. Its three dot-separated parts are a base64url-encoded JSON header naming the algorithm, a base64url-encoded JSON payload holding the claims, and a signature computed over those first two parts.
Can a JWT be decoded without the secret key?: Yes. The header and payload are only base64url-encoded, so this page shows them the instant you paste a token, with no key at all. The secret or public key matters only for proving the signature is genuine, which is exactly why a JWT payload should never carry passwords or other secrets.
How do I check if a JWT has expired?: Paste it and look at the badge above the header: it reads Expired with the time elapsed, or Valid with the time remaining, comparing the exp claim to your computer's clock. The exp row underneath gives the exact UTC instant, and a token without an exp claim gets no badge at all.

Related tools on BrakeTools

Epoch / Unix Timestamp Converter — Convert between a Unix timestamp and a human-readable date, either direction.
Hash Lab & Identifier — Compute and identify SHA-1/256/384/512, HMAC, and MD5 hashes, verify file checksums, and test password strength.
JSON Formatter & Type Generator — Format, minify, and generate types from JSON payloads up to 100MB+, no freeze.
API Request Builder & Tester — Build HTTP requests, inspect timing, headers, and responses, and copy cURL without sending request data through BrakeTools.

Content reviewed 2026-09-27.