JWT Decoder

How it works

How do I decode a JWT without uploading it?

A JSON Web Token is three base64url-encoded segments joined by dots:

header.payload.signature

Decoding the first two is trivial — base64url is an encoding, not encryption, so anything that can read base64 can read a JWT. That is exactly why where you decode it matters. This decoder runs entirely in your browser: the token is never sent to a server, never logged, and never leaves the machine you pasted it on.

That distinction is not academic. Production tokens carry user IDs, email addresses, role and scope claims, tenant identifiers and session references. Pasting one into a hosted decoder hands all of it to a third party.

What are the three segments?

• Header — metadata about the token itself, chiefly alg (the signing algorithm) and often kid (which key signed it).
• Payload — the claims: the actual assertions the token makes.
• Signature — proof the first two parts were not altered, computed with a secret or private key.

What are the registered claims?

Any application can invent its own claims, but a small set is standardised in RFC 7519 and worth recognising on sight:

exp, nbf and iat are all Unix timestamps in seconds, not milliseconds — a factor-of-1000 mistake here is one of the most common causes of tokens that appear to expire in 1970 or in the year 56000.

HS256 vs RS256 vs ES256 — which should I use?

All three are signing algorithms named in the header’s alg field, but they split into two families with a real practical difference. HS256 (HMAC-SHA256) is symmetric: the same secret both signs and verifies a token, so anything able to verify a token can also forge one — fine for a single backend that issues and checks its own tokens, risky the moment a second service needs to verify tokens without being trusted to issue them. RS256 and ES256 are asymmetric: a private key signs, a separate public key verifies, so any number of services can verify tokens using only the public key, without ever being able to forge one.

In practice: HS256 suits a single-service setup where only your own backend checks the signature. Reach for RS256 or ES256 the moment more than one service — a mobile backend, a partner API, a microservice — needs to verify tokens it did not issue. ES256 (ECDSA) produces shorter signatures than RS256 for equivalent security and is increasingly the default in newer systems, but RS256 remains more widely supported by older libraries.

This tool verifies HS256 only, for exactly the reason above: it is the one algorithm a shared secret can actually check. RS256 and ES256 need the issuer’s public key, which this tool does not currently accept as an input — pasting a secret against one of those tokens correctly reports "unsupported algorithm" rather than a false result.

How does signature verification actually work?

For HS256, the mechanism is exactly what it sounds like. The header and payload segments — the two parts before the final dot — are joined with a dot between them, and that combined string is run through HMAC-SHA256 with your secret as the key. If the result, base64url-encoded, matches the token’s own signature segment exactly, the token was signed with that secret and has not been altered since; change even one character of the header or payload and the recomputed signature comes out completely different. That single comparison, run locally in your browser with no network call, is the entire check this tool performs.

What is algorithm confusion, and why does it matter?

A known attack class, documented since around 2015, exploiting systems that accept more than one algorithm without pinning which one a given key is actually for. The classic version: an application expects RS256 and verifies against a known public key, but its JWT library will also try HS256 — an attacker forges a token signed with HS256, using the public key itself as the HMAC secret (public keys are, after all, public), and a careless verifier accepts it because it never checked that the algorithm in the header matched the one the key was issued for. The defence on your own systems is to always pin the expected algorithm explicitly rather than reading it from the token’s own header — the header is attacker-controlled input, and trusting it to choose how to verify itself defeats the verification.

Is HS256 secure? How long should my secret be?

HS256 itself is a well-regarded, widely-used algorithm — the weakness in practice is almost always the secret, not the maths. A short or guessable secret can be brute-forced offline once an attacker has a single valid token to test against, since verification is just repeated HMAC computation. RFC 8725, the JSON Web Token Best Current Practices document, recommends a symmetric key at least as long as the hash output — 256 bits (32 bytes) for HS256 — generated from a real random source, not a memorable phrase. A weak secret, not a flaw in the algorithm, is the most common way HS256 tokens actually get forged.

Can a JWT be revoked before it expires?

A JWT has no built-in network call that tells a verifier it has been revoked. A signature and an unexpired exp claim therefore do not establish that the application still accepts it. Servers can reject a token before expiry by checking a denylist, a revoked session, a token version or an appropriate key-retirement policy. Those checks require application state or key-management rules outside this decoder. Short-lived access tokens paired with revocable refresh tokens can reduce exposure, but revoking a refresh token alone does not invalidate an already issued access token unless the API also checks revocation.

Access tokens vs. refresh tokens — what is the difference?

Two different jobs, often confused because both are commonly JWTs. An access token is sent with each API request and is deliberately short-lived — commonly somewhere in the 5-to-15-minute range, though the right value depends on your risk tolerance — so a leaked one is only useful for a short window. A refresh token is longer-lived — commonly days to weeks — and is used only to obtain a new access token, typically against a server-side record that can be revoked, which is how systems built on stateless access tokens still support "log out everywhere."

How do I verify a JWT’s signature?

This tool can check that for you when the algorithm is HS256: paste the shared secret into the secret field and it recomputes the HMAC-SHA256 signature locally, in your browser, and compares it byte for byte against the token’s own signature segment. Nothing about the secret or the token is sent anywhere to do this — the same privacy guarantee as decoding, extended to verification. RS256, ES256 and other asymmetric algorithms are decoded but not verified, per the algorithm comparison above.

One honest caveat: "valid" here means the signature matches the secret *you typed in* — it says nothing about whether that secret is actually the right one. If you paste a secret you are not certain is your server’s real signing key, a "valid" result only confirms internal consistency, not that the token is genuinely yours.

Two related traps worth knowing:

• The `alg: none` attack. Some early libraries accepted a token declaring no algorithm as valid. This tool flags any alg: none token explicitly, regardless of whether you entered a secret — but pin the expected algorithm server-side too, rather than trusting the header there.
• Trusting the header’s `kid` blindly. It tells you which key the issuer claims to have used. Resolve it against a known key set, never fetch arbitrary URLs from it.

When should I reach for this tool?

Use it when you are debugging an auth flow and need to see what is actually inside a token — checking whether a claim your API expects is present, confirming an audience mismatch, working out why a session expired sooner than you thought, or confirming a token really was signed with a secret you hold. It answers those questions in a second, without the token or the secret ever leaving your device.

Claim reference

RFC 7519 defines registered JWT claims, including numeric expiry. This tool checks HS256 signatures and displays device-clock expiry separately; it is a debugging tool, not an authorization decision. RFC 8725 covers algorithm, issuer and audience validation. The OWASP JWT cheat sheet describes denylist-based revocation.

FAQ