How this tool fits your workflow
JWT structure: three Base64url-encoded parts
A JSON Web Token consists of three parts separated by dots: header.payload.signature. Each part is Base64url-encoded (URL-safe Base64 without padding). The header declares the token type and signing algorithm. The payload contains claims — statements about a subject and additional metadata. The signature verifies the token was not tampered with.
A typical header: {"alg": "HS256", "typ": "JWT"}. Common algorithms are HS256 (HMAC-SHA256, symmetric — same key signs and verifies), RS256 (RSA-SHA256, asymmetric — private key signs, public key verifies), and ES256 (ECDSA, more compact signatures than RSA). Always check the alg field — accepting "none" as a valid algorithm is a critical vulnerability.
Standard JWT claims
The payload contains registered claims (standard fields) and custom claims. Registered claims: iss (issuer — who created the token), sub (subject — whom the token refers to, typically a user ID), aud (audience — intended recipient), exp (expiration time as Unix timestamp), iat (issued-at time), nbf (not-before time — token not valid until this point).
Custom claims carry application-specific data: user roles, permissions, feature flags, or tenant IDs. Keep the payload small — JWTs are typically sent in every request as a header or cookie. Large payloads add latency. Claims that change frequently (like credits balance) are better fetched from the database on demand rather than embedded in a long-lived token.
Security pitfalls to know
Algorithm confusion: if your server accepts the client-specified alg header, an attacker can switch from RS256 to HS256 and sign the token with the server's public key (which is not secret). Always enforce the expected algorithm server-side regardless of what the token header claims.
The JWT decoder on this page decodes the header and payload without verifying the signature — it is read-only inspection. Signature verification requires the secret key or public key and must happen on the server. Never trust a decoded JWT's claims in a browser context without a server-side validation step.
Storing JWTs in localStorage exposes them to XSS attacks — any injected script can read localStorage. Storing in httpOnly cookies protects against XSS but requires CSRF protection. Short expiration times (exp) combined with refresh tokens reduce the damage window if a token is leaked.
Frequently asked questions
- Does this verify the JWT signature?
- No. The page decodes the Base64URL header and payload so you can read claims and metadata. Signature verification needs the issuer’s public key or secret and is not performed here.
- Is my token sent to a server?
- No. Parsing runs in your browser. Paste a token from staging or logs without uploading it to WebToolz365.
- Why does decoding fail for some tokens?
- JWTs use Base64URL encoding. Malformed strings, truncated copies, or non-JWT blobs will not split into three parts. Refresh the token if it expired while testing.