JWT Decoder

How JWTs work: the three-part structure

A JSON Web Token (JWT) is a compact, URL-safe string with three base64url-encoded parts separated by dots: header.payload.signature. The header declares the token type (JWT) and the signing algorithm (HS256, RS256, etc.). The payload contains claims — assertions about the subject, often including sub (subject ID), iat (issued at), and exp (expiry timestamp). The signatureis computed from the header and payload using a secret or private key, so the receiver can verify the token hasn't been tampered with.

Base64url encoding is not encryption — the payload is fully readable by anyone who has the token. Never put secrets (passwords, payment data) in a JWT payload. The signature only proves the token was issued by whoever holds the key; it doesn't hide the contents.

Reading the payload: standard claims reference

The JWT specification (RFC 7519) defines a set of registered claim names you'll encounter in most tokens:

• iss — Issuer: who created the token (e.g. https://auth.example.com)
• sub — Subject: who the token is about, usually a user ID
• aud — Audience: who the token is intended for
• exp — Expiry time as a Unix timestamp (seconds since epoch)
• nbf — Not before: token is invalid before this time
• iat — Issued at: when the token was created
• jti — JWT ID: unique identifier, used to prevent replay attacks

Everything else in the payload is a custom (private) claim specific to your application — roles, permissions, user metadata, etc.

JWT security: what this tool can't check

This tool decodes the token structure but cannot verify the signature — that requires the signing key, which should never leave the server. A decoded JWT you're reading here could have been tampered with if the signature isn't validated server-side. Key things to check in production:

• Always verify the signature using your JWT library's verify() function, not just decode(). Libraries that offer decode-without-verify exist and are a common source of vulnerabilities.
• Check the algorithm — reject tokens with "alg": "none" (a known attack vector).
• Validate expiry — check exp on every request, not just at login.
• Scope tokens tightly — use short expiry times and refresh tokens rather than long-lived JWTs.

Server-side validation: the part that matters

Inspecting a JWT in a browser tool is useful for debugging, but the security guarantee lives entirely on the server. A Node.js backend using jsonwebtoken verifies with jwt.verify(token, secret) — this validates the signature, checks exp, and throws if anything is wrong. In an Express app, this typically lives in a middleware function that runs before any protected route handler. The verified payload is then attached to req.user for downstream use.

If you're building with Railway, store your JWT secret in an environment variable (JWT_SECRET) via the Railway dashboard — never hardcode it or commit it to git.