Frequently asked questions
Common questions about JSON Web Tokens and this tool.
What is a JWT?
A JSON Web Token (JWT) is a compact, URL-safe token format defined in RFC 7519. It consists of three Base64URL-encoded parts — a header, a payload, and a signature — separated by dots. JWTs are commonly used to represent identity claims between two parties.
Is it safe to paste my JWT here?
Yes. All decoding happens entirely in your browser using JavaScript. No token data is ever sent to a server — there is no network request when you paste a token.
Can this tool verify a JWT signature?
This tool decodes and inspects a JWT — it does not verify the signature. Signature verification requires the secret or public key used to sign the token, which should never be shared publicly. Use your server-side JWT library to verify signatures.
What is the difference between HS256, RS256, and ES256?
These are signing algorithms. HS256 uses a shared secret (HMAC-SHA256) — both issuer and verifier need the same key. RS256 uses an RSA key pair — the issuer signs with a private key and verifiers use the public key. ES256 uses an elliptic curve key pair (ECDSA-SHA256) and is more compact than RS256.
Why does my token say it is expired?
JWTs contain an "exp" (expiration) claim — a Unix timestamp after which the token is no longer valid. If the current time is past that timestamp, the token is expired. Short expiry windows are a security best practice.
What should I store in a JWT payload?
Only non-sensitive claims that the recipient needs — such as user ID, roles, or permissions. Never store passwords, credit card numbers, or other secrets in a JWT payload, as the payload is only Base64-encoded (not encrypted) and can be decoded by anyone.
Where should I store JWTs on the client?
The safest option is an HttpOnly, Secure, SameSite=Strict cookie, which is inaccessible to JavaScript and resistant to XSS attacks. Avoid storing tokens in localStorage or sessionStorage, as any injected script can read them.
What is the "alg: none" vulnerability?
Some early JWT libraries accepted tokens with "alg": "none" in the header, treating them as valid without a signature. Attackers could strip the signature and forge arbitrary tokens. Always explicitly specify allowed algorithms on your server and reject "none".
How long should a JWT be valid?
Access tokens should have a short lifespan — typically 5 to 15 minutes. Use refresh tokens (stored in HttpOnly cookies) to obtain new access tokens without requiring the user to log in again. Longer-lived tokens increase the window of opportunity if a token is stolen.
Can a JWT be revoked?
Not directly — JWTs are stateless and self-contained. To revoke a token before it expires, you need a server-side blocklist (e.g. a Redis set of revoked token IDs). This reintroduces statefulness, so short expiry times are the more common approach.
What is the difference between JWT and OAuth 2.0?
JWT is a token format — it defines how to encode and sign claims as a compact string. OAuth 2.0 is an authorization framework that defines how applications request and receive access to resources. OAuth 2.0 often uses JWTs as the format for the access tokens it issues, but the two are independent concepts.
What is OpenID Connect?
OpenID Connect (OIDC) is an authentication layer built on top of OAuth 2.0. It adds an ID token (always a JWT) that tells your application who the user is — not just what they are authorized to do. Social login flows ("Sign in with Google", "Sign in with Apple") all use OpenID Connect.
Should I use JWTs or server-side sessions?
JWTs are stateless — great for microservices and API authentication since no shared session store is needed. Sessions are stateful — simpler for monolithic apps and allow instant revocation. A common pattern combines both: short-lived JWTs for API access plus a long-lived refresh token in an HttpOnly cookie for obtaining new tokens.
How does Auth0 use JWTs?
Auth0 is an identity platform that implements OAuth 2.0 and OpenID Connect. When a user authenticates, Auth0 issues access tokens and ID tokens — both are standard JWTs signed with Auth0's private key. Your application validates these tokens using Auth0's published public keys from their JWKS endpoint (/.well-known/jwks.json).