JWT Decoder & Token Inspector

Understanding JSON Web Tokens (JWT) & RFC 7519

A JSON Web Token (JWT), defined in RFC 7519, is an open, industry-standard method for representing claims securely between two parties. JWTs are compact, URL-safe, and digitally signed, making them the dominant mechanism for modern API authentication, single sign-on (SSO), and decentralized identity exchange.

1. The Anatomy of a JWT: Three Encoded Segments

In its compact serialization form, a JWT consists of three separate Base64URL-encoded strings separated by ASCII period characters (.):

[Base64URL Header] . [Base64URL Payload] . [Base64URL Signature]

• Header (Red): Identifies the token type (typically "typ": "JWT") and the cryptographic signing algorithm ("alg"), such as HS256 (HMAC SHA-256), RS256 (RSA with SHA-256), or ES256 (ECDSA).
• Payload (Purple): Contains the claims—statements about an entity (typically the user) and additional operational metadata (such as timestamps, tenant IDs, and scopes).
• Signature (Cyan): A cryptographic hash or digital signature generated by running the header and payload through the chosen algorithm with a private secret or asymmetric private key. The signature prevents tampering: if any character in the header or payload changes, the signature validation fails immediately.

2. Base64URL vs Standard Base64

JWTs do not use standard Base64 (RFC 4648 §4); they strictly use Base64URL (RFC 4648 §5). The differences are vital for web transport:

• The plus sign (+) is replaced with a hyphen (-).
• The forward slash (/) is replaced with an underscore (_).
• Trailing equals padding (=) is completely omitted.

This ensures the token can be passed safely in HTTP Authorization headers, query strings, and URL fragments without escaping or percent-encoding.

3. Standard Registered Claims Breakdown

RFC 7519 reserves a set of predefined claims that carry standardized semantic meanings. While optional, implementing them correctly is essential for secure token lifecycles:

• iss (Issuer): Identifies the identity provider or authorization server that issued the token.
• sub (Subject): The principal subject of the token (e.g., user ID or service account identifier).
• aud (Audience): Identifies the intended recipients or backend APIs that should accept the token.
• exp (Expiration Time): A Unix epoch timestamp identifying the exact moment the token becomes invalid. Verifiers MUST reject expired tokens.
• nbf (Not Before): The epoch timestamp before which the token MUST NOT be accepted.
• iat (Issued At): The epoch timestamp recording when the token was created.
• jti (JWT ID): A unique string identifier for the token, primarily used to prevent replay attacks by maintaining a revocation blacklist.

4. Common Security Pitfalls & Vulnerabilities

• Confusing Authentication with Encryption: Standard JWTs (JWS) are signed, not encrypted. Any client, proxy, or rogue actor can decode and read the JSON payload instantly. Never place plaintext passwords, credit card numbers, or sensitive PII inside a JWT unless using JWE (JSON Web Encryption, RFC 7516).
• The "alg": "none" Attack: Malicious actors historically bypassed authentication by changing the header algorithm to "none" and removing the signature. Modern JWT verification libraries reject "none" unless explicitly configured for testing.
• Algorithm Confusion (Key Confusion): When servers support both symmetric (HS256) and asymmetric (RS256) ciphers, attackers can submit a token signed with the server's public RSA key using HS256. If the backend naively verifies with its public key using HMAC, the verification succeeds. Backend servers must enforce strict algorithm whitelisting.
• Storage Vectors (XSS vs CSRF): Storing JWTs in localStorage leaves them vulnerable to Cross-Site Scripting (XSS). Storing them in HttpOnly; Secure; SameSite=Strict cookies mitigates JavaScript access while safeguarding against Cross-Site Request Forgery.

5. Frequently Asked Questions (FAQ)

Is this JWT decoder safe to use with production tokens?

Yes. This tool operates 100% locally in your web browser. No token data, claims, or headers are ever transmitted to QuickCoderHub servers or any third-party API.

Why does this tool not verify the signature?

Validating a cryptographic signature requires your private signing secret (for HS256) or your public key certificate (for RS256/ES256). Providing cryptographic secrets to third-party websites violates core security hygiene. Token verification must always be performed in your application backend.

Can I edit the payload and re-sign the token here?

No. Re-signing requires access to your private key. Any modification to the payload will immediately invalidate the existing cryptographic signature.

What is the difference between JWS, JWE, and JWT?

JWT is the overarching standard for claims representation. JWS (JSON Web Signature) represents signed, transparent tokens (what is commonly called a JWT). JWE (JSON Web Encryption) represents encrypted tokens where the payload is ciphered and unreadable without the decryption key.