Demystifying JWT: How to Debug and Verify JSON Web Tokens Safely

What is a JSON Web Token (JWT)?

In modern distributed web architectures, microservices, and Single Page Applications (SPAs), session management has evolved from server-side memory sessions to stateless, cryptographically signed tokens. Defined by RFC 7519, a JSON Web Token (JWT) is an open, industry-standard method for securely transmitting information between parties as a compact JSON object.

Because JWTs are digitally signed (using either a shared secret with HMAC or a public/private key pair using RSA or ECDSA), the receiving server can verify the sender's identity and ensure that the payload claims have not been tampered with in transit.

---

Anatomy of a JWT: The 3 Dot-Separated Segments

A standard JWT consists of three distinct parts separated by periods (.):

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFsZXggUml2ZXJhIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

1. Header (Red)

Contains the metadata identifying the token type and the cryptographic hashing algorithm used:

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

2. Payload (Claims)

Contains the actual statements and user identity attributes (claims):

{
  "sub": "usr_998124",
  "name": "Jane Doe",
  "role": "engineer",
  "iat": 1724000000,
  "exp": 1724003600
}

Standard registered claims defined by RFC 7519 include:

• iss (Issuer): Who generated the token
• sub (Subject): Unique user ID
• exp (Expiration Time): Unix timestamp after which token is invalid
• nbf (Not Before): Token cannot be accepted before this timestamp
• iat (Issued At): When the token was generated
• aud (Audience): Recipient that the token is intended for

3. Signature (Blue)

Created by taking the Base64URL-encoded header, the Base64URL-encoded payload, a secret key, and passing them through the specified cryptographic algorithm:

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  your_256_bit_secret
)

---

The Critical Security Distinction: Encoded vs. Encrypted

One of the most dangerous misconceptions among junior web engineers is believing that a JWT encrypts data.

[!WARNING]
A standard JWT is NOT encrypted; it is merely Base64URL-encoded and digitally signed. Anyone who intercepts the token can read the header and payload immediately without needing your private key. Never store passwords, API secret keys, credit card numbers, or sensitive PII inside JWT payload claims!

You can test this yourself right now using our in-browser JWT Parser & Debugger or our Base64 Encoder/Decoder.

---

Top 3 Common JWT Security Vulnerabilities

1. The Notorious "None" Algorithm Exploit

In flawed JWT verification libraries, attackers can modify the header to {"alg": "none"}, strip the signature segment entirely, and present modified payload claims (such as "admin": true). If your backend does not explicitly reject tokens where alg === "none", unauthorized privilege escalation occurs.

2. Key Confusion Attacks (HMAC vs RSA)

When a server expects an asymmetric RSA public key (RS256), but an attacker sends a token signed with HMAC (HS256) using the server's public key as the HMAC secret, poorly written verification middleware may use the public key string to validate the signature, accepting forged tokens.

3. Weak Symmetric Secrets

If an application uses HMAC-SHA256 with a simple dictionary word like "secret" or "password123", attackers can take a captured token and run offline brute-force hash cracking using tools like Hashcat or our MD5/SHA-256 Hash Tool within seconds.

---

Best Practices for Secure JWT Implementation

• Always enforce short expiration windows (e.g., 15 minutes for Access Tokens) combined with HTTP-Only Refresh Tokens.
• Store tokens in Secure, SameSite=Strict HTTP-Only Cookies instead of localStorage to protect against Cross-Site Scripting (XSS) credential theft.
• Validate iss, aud, and exp claims on every single API request before executing business logic.
• Use Strong Cryptographic Keys: Ensure HMAC secrets are at least 256 bits of high-entropy randomness generated with cryptographically secure PRNGs.
• Use our local JWT Parser & Debugger during local development to inspect token headers and payload claims without sending your authentication credentials to remote third-party inspection servers.