JWT Decoder

What is a JWT?

A JSON Web Token (JWT, pronounced "jot") is a compact, signed JSON object defined in RFC 7519. It carries claims between two parties, typically between an auth server and an API. The server issues the token after successful authentication, and the client attaches it to every API call via the `Authorization: Bearer ...` header.

JWTs consist of three base64url-encoded parts joined by dots. They are not encrypted, only signed. Anyone who has the token can read its contents, which is why passwords and other secrets must never go into the payload.

The advantage over server-side sessions: a JWT is self-contained. An API server can validate the token and extract permissions without contacting the auth server or querying a session store. That scales horizontally beautifully, but at the cost of revoking individual tokens early.

Header, payload, signature explained

Every JWT has three parts, joined by single dots:

• Header: a small JSON object with `alg` (algorithm, e.g. HS256, RS256, ES256) and `typ` (usually "JWT"). Sometimes also `kid` (key ID) as a hint about which key was used to sign.
• Payload: a JSON object holding the claims. Standard fields are `iss` (issuer), `sub` (subject), `aud` (audience), `exp` (expiration), `nbf` (not before), `iat` (issued at) and `jti` (unique token ID). Custom fields are allowed alongside.
• Signature: computed over `base64url(header) + "." + base64url(payload)` with the configured algorithm. It protects integrity: without the key, the contents cannot be modified unnoticed.

Important: base64url is encoding, not encryption. The header and payload are readable to any observer.

JWT vs. session cookies

Both approaches preserve an authenticated state, but in different ways:

• Session cookie: opaque ID, the server uses it to look up the full state in the session store. Revocation is instant, but each request costs a lookup.
• JWT: carries the state itself, secured only by signature. No lookup needed, perfect for microservice architectures, but pre-expiry revocation requires an allow/deny list.
• Size: JWTs typically run 300 to 1500 bytes. Session IDs are usually around 32 bytes. With many API calls, JWT size adds up in bandwidth.
• Storage: cookies (HttpOnly, Secure, SameSite) are the safer storage location for browsers. localStorage is exposed to XSS.

Rule of thumb: stick with sessions for pure server apps, use JWTs for API gateways and mobile backends, ideally with short lifetimes and a refresh-token flow.

JWT security: what to do about `algorithm: none`?

JWTs have seen several spectacular library bugs in recent years. The biggest pitfalls:

• `alg: none`: several libraries used to accept unsigned tokens whenever the header claimed so. Fix: never allow `none`, hardcode the permitted algorithm on the server.
• HS256/RS256 confusion: an attacker signs a token using the RSA public key as the HMAC secret, the server validates it as HS256 instead of RS256, and is fooled. Defense: the allowed `alg` is fixed on the server.
• `kid` injection: the `kid` field points at a key, but if unsanitized it can lead to path traversal or SQL injection. Treat the value as untrusted input.
• Weak secrets: HS256 tokens with "secret" or "password" as the key fall to brute force in seconds. Use at least 256 random bits, ideally from `crypto.getRandomValues()` or `/dev/urandom`.
• Long lifetime: every issued JWT is valid until expiry, even after a user has "logged out". Use short lifetimes (15 min) plus a refresh-token flow, or a deny list for sensitive endpoints.

The OWASP cheatsheets and RFC 8725 (JWT Best Current Practices) are mandatory reading.

How do I validate a JWT?

A complete validation covers far more than just the signature. Order in the server code:

• Parse the header, check `alg` against an allowlist (e.g. RS256 only).
• Verify the signature with the key matching the issuer config. With JWKS, use `kid` for the lookup, but whitelist its values first.
• Check standard claims: `iss` matches the expected issuer, `aud` contains your own audience, `exp` is in the future, `nbf` and `iat` are in the past (allow a small clock-skew tolerance).
• Validate your custom claims (roles, tenant ID, scopes) against your business model.
• If early revocation is required, check the deny / logout list.

Rely on an established library (jose, jjwt, jsonwebtoken etc.), not on hand-written code. Crypto is not a hobby project.

Host your auth backend at KernelHost

A JWT issuer and resource server needs a reliable, low-latency backend. KernelHost runs its own VPS and dedicated servers in Frankfurt FRA01 with DDoS protection, IPv4 + IPv6 and 1 Gbit/s uplink. Low RTT to European end users, fair pricing, no vendor lock-in. Company seat Vienna (AT), data center Frankfurt (DE).

JWT FAQ