JWT Decoder

Client-Side JWT Debugger & Decoder

100% In-Browser • Zero Server Uplink

Encoded JSON Web Token:

Header (Algorithm & Token Type):

Payload (Claims Data):

Architecture & RFC 7519 Token Mechanics

A JSON Web Token (JWT) is an open industry standard standardized under RFC 7519 for securely transmitting verifiable assertions between distributed microservices. In its compact serialization format, a JWT represents three distinct, period-delimited (.) Base64URL-encoded octet sequences: the JOSE Header (RFC 7515), the Claims Set Payload, and the cryptographic JWS Digital Signature or JWE Ciphertext.

Decoding client-side operates on Base64URL encoding rules established in RFC 4648 Section 5. Base64URL substitutes standard Base64 characters + and / with safe equivalents - and _, omitting trailing padding delimiters (=). To reconstruct valid JSON objects across native ECMAScript engines without truncation, the pipeline normalizes the character table, applies explicit byte padding to multiples of 4, and pipes the output through a native TextDecoder instance to prevent multi-byte Unicode sequence corruption.

Zero-Dependency Production Decoder (Node.js & Modern JS)

// High-throughput UTF-8 safe parser with zero third-party dependencies
function parseJwtUnverified(token) {
  if (typeof token !== 'string') throw new TypeError('Token must be a string');
  const segments = token.trim().split('.');
  if (segments.length < 2) throw new Error('Invalid compact serialization');

  const decodeSegment = (str) => {
    let base64 = str.replace(/-/g, '+').replace(/_/g, '/');
    while (base64.length % 4) base64 += '=';
    const binStr = atob(base64);
    const bytes = Uint8Array.from(binStr, (c) => c.charCodeAt(0));
    return JSON.parse(new TextDecoder('utf-8').decode(bytes));
  };

  return {
    header: decodeSegment(segments[0]),
    payload: decodeSegment(segments[1]),
    hasSignature: segments.length >= 3 && segments[2].length > 0
  };
}

• Memory Safety & Unicode Decoding: Standard browser atob() directly throws exceptions or produces corrupted surrogate pairs when encountering non-ASCII UTF-8 strings. Routing output through a native Uint8Array via TextDecoder guarantees robust deserialization across internationalized claim payloads.
• Zero-Trust Secret Isolation: Parsing claims purely on the client runtime ensures enterprise bearer tokens containing sensitive identity assertions (e.g., PII, internal subnet scopes) are never transmitted across public networks to arbitrary third-party verification endpoints.

JWS Cryptographic Algorithms Specification (RFC 7518)

Algorithm (alg)	Primitive Family	Key Infrastructure	Security Considerations
HS256 / HS384 / HS512	HMAC with SHA-2	Symmetric Shared Secret	High verification speed; requires secure shared secret distribution.
RS256 / RS384 / RS512	RSASSA-PKCS1-v1_5	Asymmetric (RSA 2048+)	Standard OAuth2/OIDC profile. Allows trust verification via JWKS endpoints.
ES256 / ES384	ECDSA (NIST Curves)	Asymmetric (P-256 / P-384)	Significantly smaller signature payload size; highly optimized for mobile devices.
none	Unsecured JWS	None (No Signature)	Dangerous anti-pattern. Must be strictly rejected by validation middleware.

Critical Security Pitfalls & Edge Cases

The "alg: none" Signature Bypass Vulnerability

RFC 7518 specifies an algorithm named none to accommodate unsecured tokens. Flawed backend validation libraries that derive verification logic dynamically from the token's unverified header will accept altered payloads containing elevated privileges (such as "admin": true) if the signature segment is stripped. Modern production authorization engines must enforce static algorithm allowlists independent of header directives.

Confusing Decoding with Verification

Base64URL is an encoding scheme, not an encryption algorithm. Any party in possession of a token can read its header and claims set payload in cleartext. Front-end code should treat decoded claims solely as presentation hints (e.g., rendering user display names); security-critical routing and state authorization decisions must depend exclusively on server-side cryptographic signature verification against verified public keys.

Technical FAQ

Q: Why should developers avoid storing JWTs in Browser LocalStorage?

Data persisted in localStorage is accessible by any JavaScript running in the document domain context. If your application incurs a Cross-Site Scripting (XSS) vulnerability via injected third-party tags or compromised dependencies, malicious scripts can read and exfiltrate long-lived bearer tokens. Modern architectures store sensitive session tokens in HttpOnly, Secure, SameSite=Lax/Strict cookies.

Q: What is the purpose of the "kid" (Key ID) header claim?

The kid parameter signals to verifying backend resource servers which exact cryptographic key pair was used by the identity provider to sign the token. This allows identity platforms to perform rolling key rotations via JSON Web Key Sets (JWKS) without invalidating active sessions.

Q: How does a JWT handle clock drift between servers?

Standard validation engines configure an explicit "leeway" window (typically 30 to 60 seconds) when evaluating temporal claims like exp (Expiration Time) and nbf (Not Before). This small threshold accounts for slight Network Time Protocol (NTP) unsynchronization across distributed server clusters.