> decode | inspect | verify <

A: JWT (JSON Web Token) is an open standard (RFC 7519) for securely transmitting information between parties as a JSON object. It is compact, URL-safe, and commonly used for authentication and information exchange in web applications.

A: A JWT consists of three parts separated by dots: the Header (algorithm and token type), the Payload (claims and data), and the Signature (verification hash). Each part is Base64URL-encoded.

A: Yes, the header and payload of a JWT can be decoded by anyone since they are simply Base64URL-encoded (not encrypted). The secret key is only needed to verify the signature. This is why you should never store sensitive data in a JWT payload.

A: Sessions store state on the server and use a session ID cookie. JWTs are stateless — the token itself contains all necessary information. JWTs are better for distributed systems and APIs, while sessions offer easier revocation and smaller request sizes.

A: The exp claim in the JWT payload specifies the expiration time as a Unix timestamp (seconds since epoch). After this time, the token should be considered invalid. This decoder checks the exp claim and shows whether the token is still valid or expired.

A: Paste the JWT (the full three-segment string separated by dots) into the input area. The decoder automatically splits the token on the . delimiters, Base64URL-decodes each segment, and pretty-prints the header and payload as JSON. It also extracts the algorithm, the exp claim, and flags whether the token is still valid. Decoding happens entirely in your browser — tokens are never uploaded to any server, so you can safely paste production access tokens.

A: A JWT is three Base64URL-encoded segments separated by dots: xxxxx.yyyyy.zzzzz.
1. Header — describes the signing algorithm and token type, e.g. {"alg":"HS256","typ":"JWT"}.
2. Payload — the claims, e.g. {"sub":"1234567890","name":"John","iat":1516239022,"exp":1516242622}.
3. Signature — an HMAC or RSA/ECDSA signature computed over base64url(header) + "." + base64url(payload), then Base64URL-encoded.
Full example (decoded):
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 → {"alg":"HS256","typ":"JWT"}
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ → {"sub":"1234567890","name":"John Doe","iat":1516239022}
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c → the signature bytes

A: RFC 7519 defines seven registered claims:
• iss (issuer) — who created the token (e.g., "https://accounts.example.com")
• sub (subject) — the principal the token is about, usually a user ID
• aud (audience) — who the token is intended for; the recipient must verify this matches them
• exp (expiration time) — Unix timestamp after which the token is invalid
• nbf (not before) — Unix timestamp before which the token must not be accepted
• iat (issued at) — Unix timestamp of when the token was created
• jti (JWT ID) — a unique identifier to prevent replay attacks
All are optional but widely used. Applications can add custom claims, and OpenID Connect adds specific ones like nonce, email, name.

A:
• HS256 / HS384 / HS512 — HMAC with SHA-2; symmetric, uses a shared secret. Fast, simple, good for tokens issued and verified by the same service.
• RS256 / RS384 / RS512 — RSA signature with SHA-2; asymmetric, uses a public/private key pair. Verifiable by anyone with the public key.
• ES256 / ES384 / ES512 — ECDSA signatures; smaller keys and signatures than RSA, same asymmetric model.
• PS256 / PS384 / PS512 — RSA-PSS, a more modern RSA signature scheme.
• EdDSA — Ed25519/Ed448 signatures; modern, fast, secure.
• none — explicitly no signature. Never accept this for security-critical tokens; it was the source of many CVE advisories in early JWT libraries.

A: By default, no. A signed JWT (JWS) is Base64URL-encoded but not encrypted — anyone who intercepts the token can read the header and payload. The signature only proves the token was issued by someone holding the signing key; it does not hide the contents. If you need confidentiality, use JWE (JSON Web Encryption, RFC 7516), which wraps an encrypted payload. In practice, most production systems use plain signed JWTs over HTTPS, and avoid putting sensitive data in the payload.

A: Verification requires the signing key (the shared secret for HMAC, or the public key for RSA/ECDSA/EdDSA). The steps: (1) split the token on ., (2) Base64URL-decode the header, (3) check the alg matches what your application expects, (4) recompute the signature over <header>.<payload> using the same algorithm and key, (5) compare byte-for-byte with the provided signature. Most languages have libraries that do all this in one call: jsonwebtoken (Node.js), PyJWT (Python), jjwt (Java), golang-jwt/jwt (Go). Our online decoder does not verify signatures — it only inspects the contents — because that would require you to paste your private secret.

A:
• Accepting alg: none — always pin the expected algorithm on the verifier side.
• Algorithm confusion — a token signed with HS256 using your public RSA key as the "secret" will verify if your library trusts the alg header. Pin the algorithm.
• Weak HMAC secrets — use a secret of at least 256 bits (32 bytes) of real entropy, not a password.
• No expiration check — always validate exp.
• Missing audience check — always validate aud matches your service; otherwise a token intended for service A may be replayed against service B.
• Storing tokens in localStorage — XSS can steal them; use HttpOnly cookies when possible.
• No revocation — JWTs are stateless, so you cannot invalidate one before exp. Use short expirations and a refresh-token pattern, or maintain a denylist.

A: The most common causes:
• The token is truncated — check for missing characters at the start or end
• Extra whitespace or line breaks inserted during copy-paste — paste again as a single line
• The header or payload isn't valid Base64URL (contains + / or = — those are standard Base64, not JWT)
• The token is actually a JWE (encrypted JWT), which has five segments instead of three
• The token is an opaque session ID (not a JWT at all) — JWTs always start with eyJ because {"alg" in Base64URL always begins with eyJ
If the first segment doesn't begin with eyJ, it is very likely not a JWT.

A: A JWT is a self-contained, signed, Base64URL-encoded JSON document — the recipient can read the claims directly without querying any database. An opaque token is a random identifier (e.g., 8f0e5c7a2d9b41a6...) that the server must look up in a session store to resolve to user data. JWTs trade opacity for scalability (stateless, no DB lookup); opaque tokens trade scalability for easier revocation and smaller size.