JWT Decoder

What is a JWT?

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact, self-contained way to securely transmit information between parties as a JSON object. JWTs are widely used for authentication and authorization in modern web applications — particularly in REST APIs and Single Page Apps (SPAs). After a user logs in, the server issues a JWT that the client sends with every subsequent request to prove identity.

A JWT looks like three Base64URL-encoded strings separated by dots: xxxxx.yyyyy.zzzzz

Three-Part Structure

Every JWT is made up of exactly three parts separated by dots. This structure is not arbitrary — each part serves a distinct security purpose. Understanding what belongs in each section, and crucially what should never be placed there, is the foundation of using JWTs safely in production. A common misconception is that Base64-encoding the payload provides some protection; it does not — the payload is trivially decodable by anyone who holds the token.

{
  "alg": "HS256",
  "typ": "JWT"
}

{
  "sub": "user_123",
  "name": "Alice",
  "exp": 1893456000
}

HMACSHA256(
  base64(header) +
  "." +
  base64(payload),
  secret
)

Standard Claims (Registered)

The JWT specification defines a set of reserved claim names with well-known meanings across all JWT libraries and services. Using these standard claims — rather than inventing your own field names — ensures interoperability with any framework that validates tokens. Of these, exp is the most critical: a token without an expiry can never be invalidated short of rotating your entire signing secret, which is a serious operational problem in production systems.

Signing Algorithms

The algorithm you choose determines who can verify the token and what key material is required. Symmetric algorithms like HS256 use the same secret for both signing and verification — simple and fast, but every service that needs to validate tokens must share that secret. Asymmetric algorithms like RS256 and ES256 split this responsibility: only the issuer holds the private key, while any downstream service can verify tokens using only the public key, without ever having access to the signing secret.

Security Considerations

JWTs are widely misused from a security perspective. Because decoding a token is trivial — it's just Base64 — developers sometimes assume the encoding provides confidentiality. It does not. The security of a JWT comes entirely from its signature, and only if the server validates that signature correctly on every single request. Skipping even one validation step opens the door to token forgery, privilege escalation, and session hijacking. These are the vulnerabilities that come up most often in real-world security audits and bug bounty reports.

// Security Warnings
! alg:none — tokens with no algorithm are unsigned and must always be rejected
! Weak secrets — HS256 secrets shorter than 32 bytes are brute-forceable
! Algorithm confusion — always validate the algorithm server-side; never trust the header alone
! JWT payload is only Base64-encoded, not encrypted — never store sensitive data in claims
! Always validate exp, iss, and aud claims server-side on every request
! Use short expiry times (15–60 min) and refresh token rotation for long sessions
* This inspector decodes for inspection only — always verify tokens server-side in production