JWT Decoder & Encoder: Decode, Verify and Sign

Decoding is not verification, and the gap is where the bugs live

Almost every “JWT debugger” blurs this line, and the blur causes real outages and real breaches. Decoding a JWT is a pure text transformation: swap the Base64URL alphabet back, restore the stripped padding, run it through a Base64 decoder, parse the JSON. No key is involved, no secret is needed, and it works on a token you invented thirty seconds ago in a text editor. Verification is a different operation entirely — it recomputes the signature over the exact bytes base64url(header) + "." + base64url(payload) using the signing key, compares it to the third segment, and only then does the payload mean anything.

Everything in the right-hand column is unanswerable on this page, by design. The expiry badge above is a statement about what the exp number literally says, not a verdict on whether the token is genuine — a forged token can carry any expiry an attacker likes. Use a decoder to understand a token; use a maintained library with the real key, server-side, to trust one.

Three segments, two of them readable by anyone

The structure is header.payload.signature. The first two are JSON objects run through Base64URL — the URL-safe variant of Base64 that uses - and _ where standard Base64 uses + and /, with the trailing = padding stripped. That padding removal is exactly why pasting a JWT segment into a generic Base64 decoder often fails; the decoder above adds the padding back before decoding.

• Header— metadata about the signature. alg names the algorithm, typ is usually JWT, and kid is a hint telling the verifier which key from the issuer’s key set to use. This segment is supplied by whoever produced the token, which makes it untrusted input, not instructions.
• Payload— the claims. A JSON object of registered claims (iss, sub, exp…) plus whatever custom fields the issuer adds, such as roles or a tenant id.
• Signature— raw bytes, not text. Decoding it gives you binary noise, which is why the tool shows it as-is rather than pretending to translate it.

Trivia that is genuinely useful when grepping logs: nearly every JWT starts with eyJ, because that is what {"— the opening of any JSON object with a quoted key — looks like once Base64-encoded. If a string in a log starts with eyJ and contains two dots, you are almost certainly looking at a leaked token.

The seven registered claims, and what a verifier should do with each

RFC 7519 registers seven claim names. All of them are optional — a JWT with an empty payload is still structurally valid — but the three time claims use a specific format called NumericDate: seconds since 1970-01-01 UTC, not milliseconds. Passing JavaScript’s Date.now() straight into exp is one of the most common home-rolled-issuer bugs there is, and it produces tokens that expire tens of thousands of years from now. The decoder flags that case explicitly.

Everything else in a payload is a private or public claim invented by the issuer: email, roles, scope, tenant_id and so on. Those carry no standard meaning, so two systems can use the same name for different things — another reason to check iss before you read a custom claim.

Which algorithm signed it, and what key you need to check it

The practical divide is symmetric versus asymmetric. With HS*, one shared secret both signs and verifies — so every service that can check a token can also forge one, which is fine inside a single application and a liability across an organisation. With RS*, PS*, ES* and EdDSA, only the issuer holds the private key and everyone else verifies with a public key, usually published at a JWKS endpoint. A useful side effect: the signature length is fixed per algorithm, so the segment-size table in the tool above often tells you whether a token’s header is being honest about its own alg.

HS*, RS*, PS* and ES* are registered in RFC 7518; EdDSA was added later by RFC 8037. The ES* and EdDSA signatures are two fixed-width halves concatenated, which is why their length never varies — unlike RSA, where the signature is exactly as long as the modulus. This table is a reference, not something the decoder acts on: it reads the alg value and describes it, but it holds no keys and runs no signature check.

The alg: none trap, and why the header must never pick the algorithm

RFC 7519 allows an “Unsecured JWT”: alg set to none, an empty signature segment, and a trailing dot where the signature would be. It exists for cases where integrity is already guaranteed by some other layer. It became notorious because of how libraries used it. A verify function whose signature looked like verify(token, key) would read alg out of the header to decide which check to run — and if the header said none, the honest implementation of “check a none signature” is to do nothing and return success. An attacker could take a real token, rewrite the payload to "role": "admin", set alg to none, drop the signature, and be let straight in. A cluster of popular JWT libraries shipped this behaviour until a 2015 disclosure forced the fix; the Node ecosystem’s instance is catalogued as CVE-2015-9235.

The subtler cousin is algorithm confusion. Suppose a service issues RS256 tokens and verifies them with the issuer’s public key — which is, by definition, public. An attacker rewrites the header to HS256 and signs their forged token using those public key bytes as the HMAC secret. A library that dispatches on the header will now compute an HMAC with the very same public key, get a match, and accept the forgery. The root cause in both attacks is identical: the token got to choose how it would be checked.

The decoder above flags alg: none in red and warns when a signature segment is empty while the header claims a real algorithm — but that is a readability aid for you, not a security control. It cannot tell a forged token from a genuine one, and nothing on this page should be treated as a pass or a fail.

Signing your own tokens, and the three tests worth running

The Encode & sign tab turns the tool around: edit the header and payload as JSON, pick an algorithm, supply a key, and it produces a real signed token. The JSON is compacted before encoding, exactly as a library would, so the token you get here is byte-for-byte what your own code should produce from the same input — which is what makes it useful for comparing against a token your service emitted. For RS, PS, ES and EdDSA you do not need to bring a key at all: Generate a key pair creates one with crypto.subtle.generateKey, hands you both halves in PEM form, and keeps neither.

The reason to sign a token by hand is almost always to attack your own verifier before somebody else does. Three tests are worth running against any service that accepts JWTs:

1. The unsigned token. Set alg to none, sign nothing, and send the result. A correct verifier rejects it outright. If yours returns 200, an attacker can mint any identity they like, and no key is involved.
2. The swapped algorithm. Take a token your RS256 service issued, re-sign it here as HS256 using the service’s own public key as the HMAC secret, and send that. A verifier that reads alg out of the header instead of pinning it will treat the public key — which is not secret — as a shared secret and accept the forgery.
3. The expired token. Set exp to a time in the past and confirm you get a 401. It is a two-second check, and a surprising number of services skip the claim entirely because their library only validates exp when you ask it to.

Run these against systems you are responsible for. A token you sign here is only as meaningful as the key behind it: with a key nobody trusts it is a harmless test fixture, and with a production signing key it is a live credential that should never have been pasted into a web page in the first place — including this one.

A JWT is a live credential, so where you paste it matters

An access token is a bearer credential: whoever holds it is treated as you, no password required, until it expires. That makes it the same class of secret as a session cookie. And yet the normal debugging reflex is to paste it into whatever decoder comes up first in a search — which, for a server-rendered decoder, means the token travels over the network to a stranger’s machine, where it will at minimum pass through request logs. That is a credential disclosure whether or not anyone acts on it, and in a regulated environment it is a reportable one.

This decoder is a static page: the parsing runs in your browser’s own JavaScript, and the token is never sent anywhere, logged, or stored. You do not have to take that on faith — open your browser’s network tab while you paste, or disconnect from the internet entirely and watch the tool keep working. There are no accounts here, no saving, and no server to send anything to.

The honest caveat is that a token which has already been shared elsewhere is already compromised, and this page cannot un-share it. Pasting a production token into a chat thread, a bug report, a screenshot, or a support ticket has the same effect as posting a password. Rotate or revoke it — and note that revocation is genuinely hard with stateless JWTs, because a signed token stays valid until exp unless you maintain a denylist keyed on jti or rotate the signing key itself. Short expiry times are the usual mitigation, which is precisely why the exp readout above is worth looking at when you are triaging a leak.

Frequently asked questions