Question 1

What is a JSON Web Token (JWT)?

Accepted Answer

A JWT is a compact, URL-safe way to encode a set of claims about a subject. The full specification is RFC 7519. The serialised form is three base64url-encoded segments joined by '.': header.payload.signature. The header declares the signing algorithm, the payload carries the claims (who, when, what scope), and the signature lets a verifier confirm the token was issued by someone who held the signing key — without trusting the bearer.

Question 2

Does this decoder send my token to a server?

Accepted Answer

No. The token never leaves your browser tab. Base64url decoding, JSON parsing, and HS256 verification all run as JavaScript on this page. Open DevTools' Network tab while you decode and watch it stay silent. That said, even decoding a token locally exposes the claims to whoever sees your screen — never paste a production access token into any web tool you don't control end-to-end.

Question 3

How does HS256 verification work?

Accepted Answer

HS256 is HMAC with SHA-256. Verification takes the ASCII bytes of 'header.payload' (the first two base64url segments joined by a dot), runs HMAC-SHA-256 over them using the shared signing secret, and compares the result to the signature bytes from the third segment. This decoder uses the browser's W3C SubtleCrypto API for the hash, so the comparison is a constant-time crypto.subtle.verify and not a manual string compare.

Question 4

Why can't I verify RS256, ES256, or PS256 tokens here?

Accepted Answer

Those algorithms are asymmetric — the token is signed with the issuer's private key and verified with the matching public key (RSA for RS256/PS256, ECDSA P-256 for ES256). A shared secret isn't enough. To verify, fetch the issuer's JWKS endpoint (typically '/.well-known/jwks.json'), pick the JWK whose 'kid' matches the header, and use a server-side verifier such as 'jose', 'jsonwebtoken' with the public PEM, or your platform's IAM library. This decoder still parses both segments correctly so you can read the claims.

Question 5

What is base64url, and how is it different from base64?

Accepted Answer

Base64url is the variant defined by RFC 4648 §5 that uses '-' and '_' instead of '+' and '/' (the latter two are reserved in URLs). The JWS spec (RFC 7515 Appendix C) also drops the '=' padding. The encoded bytes are identical between the two variants — only the two non-alphanumerics and the padding rule change. This page accepts segments with or without '=' padding to be lenient with input from libraries that emit either form.

Question 6

What does 'alg: none' mean, and is it dangerous?

Accepted Answer

RFC 7519 §6.1 allows a JWT to declare no signature algorithm. The third segment is then empty. Several historic verifier libraries accepted 'alg: none' by default, which let an attacker swap a valid signed token for an unsigned one and bypass auth entirely. This decoder surfaces 'alg: none' clearly and refuses to mark the token as verified. In production, your verifier must reject 'alg: none' explicitly — never trust the header's claim alone.

Question 7

My token shows 'expired'. Is the signature still trustworthy?

Accepted Answer

Yes — expiry and the signature are independent. 'exp' is a claim inside the payload, so if the signature verifies, the issuer really did say this token expires at that time. The verifier just shouldn't accept the bearer's request after that moment. RFC 7519 §4.1.4 specifies exp as exclusive (token is expired when now >= exp). If you control the issuer, lengthen the lifetime or re-issue the token; if you don't, request a fresh one through the normal refresh flow.

Question 8

What's the difference between iat, exp, and nbf?

Accepted Answer

All three are NumericDate values — seconds since the Unix epoch. 'iat' (issued-at) records when the issuer minted the token. 'exp' (expiration) is the inclusive upper bound — the token is invalid when current time is greater than or equal to exp. 'nbf' (not-before) is the inclusive lower bound — the token is invalid when current time is less than nbf. A correctly issued token has iat <= nbf < exp; many tokens omit nbf because iat already serves as a floor.

Question 9

Why are there three segments instead of two?

Accepted Answer

The first two segments — the base64url-encoded header and payload — are what the signature is computed over. Keeping them separate from the signature segment means a verifier can read 'alg' from the header before doing any cryptography, and re-hash exactly the bytes the issuer hashed (a guarantee that string-concatenating after JSON-parsing would break). The third segment carries the raw signature bytes. A five-segment token is a different thing: JWE (RFC 7516) for encrypted JWTs, out of scope here.

Question 10

Can I edit the decoded payload and re-sign the token?

Accepted Answer

Not on this page — by design. A re-signer is a 30-line script with 'jose' (Node, browser, Deno) or 'PyJWT' (Python); building one into a public web tool would invite copy-pasting production secrets into a third-party UI, which is exactly the risk this decoder's privacy notice is trying to prevent. If you need to mint test tokens, run a local script — npm install jose, then 'await new SignJWT(claims).setProtectedHeader({alg: "HS256"}).sign(secret)'.

JWT Decoder — inspect & verify JSON Web Tokens

How it works

Worked examples

Frequently asked questions

Sources & references

Related tools

Base64

Regex Tester

URL Encoder

Comments & feedback