What is a JSON Web Token (JWT)?

A JSON Web Token (RFC 7519) is a compact, URL-safe means of representing claims securely between two parties. It is composed of three Base64URL-encoded parts separated by periods: the Header (algorithm and token type), the Payload (user claims and session data), and the Signature (cryptographic verification hash).

Are my tokens or secret keys sent to your servers?

Never. All Base64URL parsing, claim decoding, and HMAC-SHA256 signature verifications execute 100% inside your local web browser using the browser's native Web Crypto API. Sensitive production tokens and credentials never leave your machine.

What is the difference between HS256 and RS256?

HS256 (HMAC with SHA-256) is a symmetric algorithm requiring a shared secret key for both signing and verifying the token. RS256 (RSA Signature with SHA-256) is an asymmetric algorithm where the identity provider signs with a private key, and any consumer can verify using the public key.

How does the live expiry countdown timer work?

The tool reads the numeric 'exp' (Expiration Time) UNIX timestamp from the payload, compares it with the current client system clock, and updates a live countdown timer indicating exactly when the token expires or how long ago it expired.

JWT Debugger & Decoder — Inspect, Decode & Verify Web Tokens

The Architecture of JSON Web Tokens (JWT RFC 7519) & Modern API Security

JSON Web Tokens (JWT) are an open, industry-standard RFC 7519 method for securely transmitting information between parties as a compact, self-contained JSON object. Because JWTs are digitally signed using cryptographic algorithms (such as HMAC with SHA-256 or RSA/ECDSA public-private keypairs), the claims they contain can be trusted and verified by downstream microservices without querying a centralized session database.

1. The Three Building Blocks of a JWT

In its compact serialized form, a JWT consists of three separate Base64URL-encoded strings separated by periods (header.payload.signature):

Header: Typically consists of two fields: the cryptographic signing algorithm being used (e.g., "alg": "HS256" or "RS256") and the token type ("typ": "JWT").
Payload: Contains the claims. Claims are statements about an entity (typically the authenticated user or tenant) along with additional metadata such as token issue time and expiration limits.
Signature: Generated by hashing the encoded header, a dot delimiter, the encoded payload, and your private cryptographic secret key using the specified algorithm. The signature guarantees that the token has not been tampered with in transit.

2. Standard Registered Claims Dictionary (RFC 7519)

The IETF defines seven reserved, non-mandatory claims designed to provide interoperability across microservices and identity providers:

iss (Issuer): The identity provider or authorization server that minted the token (e.g. https://accounts.google.com or https://auth.company.com/).
sub (Subject): The unique identifier of the user or resource principal (e.g. UUID usr_98b4f1).
aud (Audience): The recipient or backend API service for which the token is intended. Backend services must verify their own client ID matches the audience claim before accepting incoming requests.
exp (Expiration Time): UNIX epoch timestamp after which the token is strictly invalid. Critical for mitigating token replay attacks.
nbf (Not Before): The earliest timestamp at which the token becomes valid.
iat (Issued At): The timestamp when the identity provider minted the token.
jti (JWT ID): A unique cryptographic nonce used to prevent token replay across distributed systems.

3. Symmetric (HS256) vs Asymmetric (RS256 / ES256) Architectures

Selecting the correct signing algorithm is a foundational design choice:

HS256 (HMAC-SHA256): Uses a single shared symmetric secret key for both generating the signature and validating it. HS256 is computationally fast, but requires that every microservice that validates the token has access to the exact secret key. If a single reporting microservice is compromised, the attacker can forge administrative tokens for the entire company.
RS256 (RSA-SHA256) & ES256 (ECDSA): Uses an asymmetric keypair. The identity provider signs tokens using a tightly guarded private key. All downstream microservices download the provider's public key (often published via a JSON Web Key Set / JWKS endpoint) to verify incoming tokens. Even if a downstream microservice is completely compromised, the attacker cannot forge new tokens.

4. Critical JWT Security Vulnerabilities & Prevention

When implementing token-based authentication in Node.js, Go, Python, or Java, avoid these common security flaws:

The "alg: none" Exploit: Early vulnerable JWT libraries allowed attackers to modify the header to "alg": "none", strip the signature, and submit forged admin claims. Modern authorization servers must explicitly whitelist allowed algorithms and reject "none" tokens.
Weak Shared Secrets: In HS256, short passwords (like secret123) can be cracked offline in seconds using tools like Hashcat or John the Ripper. Always use high-entropy secrets of at least 256 bits (32 random bytes).
Storing Sensitive Secrets in Payloads: Base64URL encoding is not encryption! Anyone holding the token can decode and view all claims in plaintext. Never store unencrypted passwords, API keys, or credit card numbers inside JWT payloads.

Frequently Asked Questions (FAQ)

Is a JWT encrypted or encoded? ▼

Standard JWTs (JWS) are digitally signed and Base64URL encoded, NOT encrypted. Their payload contents are readable by anyone who inspects the token. If payload confidentiality is required, you must use JSON Web Encryption (JWE) as specified in RFC 7516.

Where should JWTs be stored in web browsers? ▼

To defend against Cross-Site Scripting (XSS) attacks, tokens should be stored in secure, HttpOnly, SameSite cookies rather than browser localStorage or sessionStorage. HttpOnly cookies cannot be accessed by malicious client scripts injected onto the page.

How long should an access token's lifetime be? ▼

Best practices dictate short access token lifetimes, typically between 5 and 15 minutes. Long-lived sessions should be managed using refresh tokens stored securely on the backend with automated token rotation and revocation lists.

Can I invalidate or revoke a JWT before it expires? ▼

Because JWTs are stateless, they remain valid until their 'exp' timestamp passes. To support immediate revocation (e.g. user logout or password reset), architectures maintain a lightweight Redis token blocklist or increment a user token version counter checked on critical operations.