What a JWT is
A JSON Web Token (JWT, RFC 7519) is a compact string that carries a JSON header and payload, optionally protected by a signature or authenticated encryption. The common signed form looks like three Base64URL segments separated by dots:
base64url(header) . base64url(payload) . base64url(signature)
The payload typically includes claims such as subject (sub), audience (aud), expiration (exp), and application-specific fields. Because the payload of a signed (not encrypted) JWT is only encoded, anyone who obtains the token can read the claims. The signature’s job is to detect tampering and, with a shared secret or public key, confirm who issued the token.
Inspect a sample token with the Decode JWT tool—decoding alone does not prove the signature is valid.
Subtools in this family
- Decode JWT — splits and Base64URL-decodes header and payload so you can read algorithms and claims locally in the browser.
- Sign JWT HS256 — builds a token from a JSON payload and shared secret using HMAC-SHA256.
- Verify JWT HS256 — recomputes the HMAC-SHA256 signature with your secret and reports whether it matches.
Typical learning path: sign a throwaway payload, decode it to inspect claims, then verify with the same secret. Changing any character of the payload should make verification fail.
HS256 and the role of HMAC
HS256 means HMAC-SHA256 over the header and payload segments. Both issuer and verifier share a secret. That model fits first-party APIs and simple session tokens. It is a poor fit when many untrusted clients must verify tokens without holding the issuer secret—there you want asymmetric algorithms (RS256, ES256) with a public JWKS.
HS256 verification is only as strong as secret storage. Embedding the secret in a public mobile app or front-end bundle lets anyone forge tokens.
For the underlying MAC construction, see also the HMAC hub, especially HMAC SHA-256.
Claims you should treat carefully
exp / nbf / iat. Expiration and not-before windows prevent indefinite reuse. Verifiers must reject expired tokens; decoders that only print JSON will not enforce time for you.
alg. The header advertises the algorithm. Hard-code the expected algorithm on the verifier (HS256 only, for example). Historical vulnerabilities involved accepting alg: none or switching from RS256 to HS256 while treating a public key as an HMAC secret.
aud and iss. Audience and issuer checks stop tokens minted for one service from being accepted by another.
Sensitive data in payloads. Prefer opaque identifiers over raw personal data in unencrypted JWTs. Remember logs, browser history, and Referer headers can leak tokens.
Decode versus verify
| Operation | Proves readability | Proves authenticity |
|---|---|---|
| Decode | Yes (for non-encrypted JWT) | No |
| Verify HS256 | Needs secret | Yes, if secret is correct and comparison is sound |
Always verify in application code paths that authorize actions. Decoding in a debugger is for humans; cryptographic verification is for machines making access decisions.
Base64URL details
JWT uses Base64URL without padding in the classic serialization. That differs from standard Base64 (+// vs -/_). Mixing alphabets when manually rebuilding tokens is a common source of invalid signature errors. Prefer library APIs that handle encoding rather than hand-rolling string concatenation in production.
Common failure modes
- Clock skew: token just issued appears “not yet valid” or already expired—allow a small leeway if your platform documents it.
- UTF-8 and JSON canonicalization: resigning after pretty-printing JSON changes bytes and breaks signatures.
- Secret mismatch across environments (staging vs production).
- Treating decode success as login success.
- Putting passwords or raw card data in JWT claims.
Limitations and environment
These tools focus on HS256 learning and debugging. They do not implement the full JOSE stack (JWE encryption, every JWA algorithm, or JWKS federation). Client-side processing keeps sample tokens on-device for casual inspection; still avoid pasting production session tokens into shared machines.
Summary
JWTs package claims in a compact, signed string. This hub lets you decode headers and payloads, sign with HS256, and verify HMAC-SHA256 signatures. Read claims cautiously, verify before trusting, protect shared secrets, and choose asymmetric algorithms when verifiers should not share the issuer’s key.