JSON Web Token (JWT) Header & Claims Inspector

Claim	Standard Meaning (RFC 7519)	Raw Token Value	Human Readable Translation
Enter a valid JWT to view claim interpretations...

Claim

Standard Meaning (RFC 7519)

Raw Token Value

Human Readable Translation

Enter a valid JWT to view claim interpretations...

The Anatomy of JSON Web Tokens: RFC 7519 and JWS Architecture

In modern web security, OAuth 2.0 authorization frameworks, and OpenID Connect (OIDC) identity layers, JSON Web Tokens (JWT) serve as the primary compact, URL-safe means of representing claims between two parties. Defined under IETF RFC 7519 and secured via JSON Web Signature (JWS, RFC 7515), a JWT encapsulates identity information without requiring round-trip database session lookups on distributed microservices.

The Three Tripartite Token Components

A standard signed JWT consists of three distinct Base64URL-encoded strings separated by dot (.) delimiters:

Segment	Color Indicator	Content Schema	Security Purpose
1. Header	Red / Rose	{ "alg": "RS256", "typ": "JWT" }	Declares cryptographic algorithm and token type.
2. Payload	Indigo / Purple	{ "sub": "123", "exp": 1774886400 }	Contains identity claims, roles, and expiration dates.
3. Signature	Cyan / Blue	HMACSHA256(base64Url(H) + "." + base64Url(P), secret)	Cryptographically prevents payload tampering and forgery.

Registered Claim Names and Temporal Validation

RFC 7519 reserves a set of standardized claims providing interoperable authorization semantics:

iss (Issuer): Identifies the principal security authority that issued the token (e.g. https://auth.company.com/).
sub (Subject): The unique identifier of the user or machine entity.
aud (Audience): Identifies the intended recipients (e.g., target API microservices).
exp (Expiration Time): The UTC timestamp after which the token MUST NOT be accepted.
nbf (Not Before) & iat (Issued At): Delineate the temporal validity window of the token.

Architectural Vulnerabilities and Client-Side Token Hygiene

While JWTs solve horizontal stateless scaling challenges, developers must guard against common pitfalls:

Confidentiality Myth: Standard JWTs are signed, not encrypted. Any client or intermediary can decode the Base64URL payload. Never store passwords, PII, or unencrypted secrets in JWT claims.
Storage Vector Risks: Storing JWTs in browser localStorage exposes tokens to Cross-Site Scripting (XSS) extraction. Storing access tokens in HttpOnly, SameSite=Strict cookies mitigates automated exfiltration.

Frequently Asked Questions (US Standards)

Can this tool verify the cryptographic signature of a JWT without a secret key?

No. Verifying a cryptographic signature requires either the symmetric secret key (HMAC SHA-256) or the public key of the issuing certificate (RS256/ES256). This tool parses and decodes the Base64URL-encoded Header and Payload claims for inspection without requiring you to share confidential signing keys.

How are the iat, exp, and nbf timestamp claims decoded?

Standard JWT claims (RFC 7519) specify times as NumericDate values—representing seconds elapsed since January 1, 1970 (UNIX Epoch). The inspector converts these integers to local ISO 8601 timestamps and computes the exact time remaining until expiration.

What is the "alg: none" vulnerability in JWT implementations?

In flawed backend JWT implementations, attackers modify the token header to set "alg": "none" and strip the signature. Vulnerable verification libraries accept the unsigned payload as valid. Modern token parsers strictly reject tokens declaring "none" unless explicitly configured in non-production environments.

Is my bearer token or authentication payload sent to an external server?

No. All Base64URL decoding, JSON parsing, and expiration telemetry execute 100% locally in your web browser. Your authentication tokens, user IDs, and claims are never transmitted across the network.