The 401 Unauthorized Mystery
You trigger an authenticated API call from your frontend or Postman, and the server abruptly responds with HTTP 401 Unauthorized or 403 Forbidden. Why? Did the token expire? Was the user role stripped from the claims? Is the audience (aud) mismatched?
To diagnose the failure, you need to look inside the JWT. But if that token was generated in a staging or production environment, pasting it into a random third-party website is a severe security violation.
A JWT often contains sensitive claims including internal user IDs, tenant roles, email addresses, and OAuth scopes. If the token is still valid, whoever captures it can impersonate that user until expiration.
Anatomy of RFC 7519: The Three Dot-Separated Segments
A JSON Web Token (RFC 7519) is a compact, URL-safe string comprised of three distinct parts separated by periods (.):
1. Header: Specifies the token type (JWT) and the cryptographic signing algorithm (such as RS256, ES256, or HS256).
2. Payload: The JSON claims set. This contains registered claims (sub, iss, exp, iat) and custom business metadata (roles, permissions).
3. Signature: The cryptographic hash created by signing the encoded header and payload with the server private key or secret.
// JWT Format Breakdown:
// eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
// [ HEADER (Base64) ].[ PAYLOAD (Base64) ].[ SIGNATURE (Binary Hash) ]Why Base64Url Is Not Standard Base64
A common mistake when decoding JWTs in custom scripts is passing the raw token string to standard atob() or base64 -d. Standard Base64 uses the characters + and /, along with = for padding.
In HTTP headers and URL query parameters, + is often converted to a whitespace, and / breaks URL paths. Base64Url solves this by replacing + with - (hyphen), replacing / with _ (underscore), and dropping trailing = padding.
To decode a Base64Url segment safely in Node.js or JavaScript:
function decodeBase64Url(str) {
// Convert URL-safe chars back to standard Base64
let base64 = str.replace(/-/g, '+').replace(/_/g, '/');
// Pad with '=' to make length multiple of 4
while (base64.length % 4 !== 0) {
base64 += '=';
}
return JSON.parse(Buffer.from(base64, 'base64').toString('utf8'));
}Decoding vs. Verification: The Golden Rule
There is a critical distinction that frontend engineers sometimes miss: Decoding a token is NOT verifying a token.
Anyone can fabricate a JWT with arbitrary claims (e.g. {"role": "superadmin"}), Base64Url encode it, and send it to your backend. Decoding simply unpacks the JSON so you can read expiration times or user names for UI rendering.
Your API backend must ALWAYS verify the cryptographic signature using the public key (JWKS) or shared secret before trusting any claim in the payload.
The exp (expiration) claim is stored in Unix Epoch Seconds, not milliseconds. To convert it in JavaScript: new Date(exp * 1000).
Private In-Browser Token Inspection with LLMScope
LLMScope JWT Decoder allows you to paste, inspect, and analyze JWT tokens with automatic expiration countdowns, Unix epoch date formatting, and header breakdown.
The decoder runs 100% in-browser using JavaScript string manipulation. No tokens are sent over the network, ensuring zero risk of credential harvesting or session hijacking.