b2KIT

JWT Cheat Sheet

Interactive JWT reference showing registered claims, common algorithms, and best practices with examples.

Tested tool guide Tested browser tools Checked August 16, 2026

What JWT Cheat Sheet does, with a checked example

A JWT is a dot-separated triple: header, payload, and signature, each a base64url-encoded piece of JSON. Paste a token into this reference and it decodes the segments, names the algorithm in the header, and annotates registered claims such as iss, sub, aud, exp, nbf, iat, and jti, alongside tables of common algorithms and best practices. The surprise most people hit: the payload is not encrypted. Base64url is plain encoding, so anyone holding the token can read its contents. The signature proves integrity and origin, not secrecy, so secrets and personal data do not belong in the payload.

Worked example

A concrete input and expected output from the current implementation.

Input

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Expected output

Header: {"alg":"HS256","typ":"JWT"} Payload: {"sub":"1234567890","name":"John Doe","iat":1516239022} iat as a date: 2018-01-18T01:40:22Z. sub is the subject, iat the issued-at time.

The first two segments are base64url-encoded JSON, so they decode to the header and payload shown. The header declares HS256, and the third segment is the signature over the first two segments. iat is a NumericDate, so 1,516,239,022 seconds after 1970-01-01 is 2018-01-18T01:40:22Z.

How the result is produced

1

Segments and registered claims

The tool splits the token on the two dots and base64url-decodes the header and payload. Base64url is standard base64 with + and / replaced by - and _, padding stripped, and every character case-sensitive. Registered claims (iss, sub, aud, exp, nbf, iat, jti) appear in the decoded payload; exp and nbf are NumericDates, seconds since the epoch. A string with a missing segment or characters outside the base64url alphabet is not a valid JWT and cannot be decoded.

2

Algorithms and the alg pitfall

The header's alg names the signing algorithm, and the signature covers the two encoded segments plus a key, never the decoded JSON. HS256 is symmetric HMAC-SHA256 with a shared secret; RS256 and PS256 use RSA key pairs; ES256 uses ECDSA. The pitfall stressed: pin allowed algorithms, since a verifier that trusts the header's alg lets an attacker re-sign an RS256 token as HS256 with the public key.

Good uses

  • You were handed a token by an identity provider (Auth0, Okta, Azure AD, a custom login server) and want to see which claims it actually carries before writing code that trusts sub, email, or exp.
  • A session keeps getting rejected mid-workflow, and you need to know whether exp has passed, whether aud matches what the API expects, or whether the string you were given is even a JWT.
  • You are about to issue your own tokens and want the decision straight: HS256 with a shared secret versus RS256 or ES256 with key pairs, and which registered claims your verifier should require.

Limits and checks

  • Decoding is not verifying. A token with a forged payload decodes identically to the genuine one; only a signature check against the correct key distinguishes them. The tool shows contents, not authenticity.
  • exp is a NumericDate in seconds since the Unix epoch, and expiry is strict: a conforming verifier rejects the token from the instant now equals exp. A payload showing exp as an ISO date string is non-conforming and will not behave as you expect.
  • Base64url is case-sensitive and unpadded, so a token copied from a wrapped log line - one with a line break, an inserted space, or a mangled character - fails to decode or decodes to garbage. Compare the pasted token character for character against the source.

Common questions

Can this tool decrypt my JWT?

No, and nothing needs decrypting. The payload is base64url-encoded, not encrypted, so the tool simply displays what anyone holding the token can already read. If confidentiality matters, the token must be a JWE (encrypted JWT, RFC 7516), whose payload is unreadable without the encryption key. The standard advice still stands: keep sensitive data server-side and put only an identifier in the token.

I decoded my token and exp looks fine, so why is it rejected?

Check the signature first: decoding succeeds on a forged token too, and an invalid signature fails verification regardless of exp. Then confirm exp is a NumericDate in seconds (an ISO timestamp is non-conforming and ignored), that now is strictly before exp, and that aud matches what the API expects, since an audience mismatch rejects a validly signed token. Finally, allow for clock skew on the verifying server.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools

Periodic Table Quiz

Interactive periodic table - click elements, enter quiz mode, and guess elements from their properties. Gamified learning.

Periodic Table Interactive Reference

Explore the periodic table with element details, properties, and category filtering.

Binary / ASCII / Unicode Character Table

Browse and search ASCII, Unicode, and binary character codes with copy-to-clipboard.

HTML Semantic Structure Quiz

Test your knowledge of semantic HTML elements with quizzes and best-practice tips.

Typing Tutor

Structured typing lessons with finger placement guide. Track WPM improvement over time with localStorage persistence.

Multiplication Table Drill

Timed multiplication drills with accuracy tracking per table (1-12). Progress chart saved across sessions.