Loading...
Loading...
Free online JWT parser and generator — decode, verify, and create JSON Web Tokens with HS256, RS256. Inspect header, payload, and signature instantly.
Header
Payload
Secret Key
JSON Web Tokens (JWT) are an open standard (RFC 7519) for securely transmitting information between parties as a JSON object. A JWT consists of three base64url-encoded segments separated by dots: the Header (containing the algorithm and token type), the Payload (containing claims like user ID, expiration, and permissions), and the Signature (used to verify the token has not been tampered with).
The payload contains claims — statements about an entity (typically the user) and additional metadata. There are three types of claims: registered claims (iss, sub, exp, iat, etc. — defined by the standard), public claims (defined by whoever uses them, should be collision-resistant), and private claims (custom claims agreed upon between parties, like user roles or permissions).
JWTs enable stateless authentication — the server does not need to store session data because all the necessary information is contained within the token itself. This makes JWTs ideal for distributed systems and microservices architectures where you want to avoid querying a central session store on every request.
However, statelessness has trade-offs. Revoking a JWT before it expires is difficult without a blocklist. Token size is larger than a session ID, which can impact bandwidth. And because the payload is only base64-encoded (not encrypted), sensitive information must never be stored in a JWT. Always use HTTPS and keep token lifetimes short.
This tool lets you decode any valid JWT to inspect its header and payload contents, or generate a new JWT for testing. When generating, you can customize the header algorithm (HS256, RS256, etc.), add custom payload claims, and set the token expiration. The generated token includes a proper signature computed using the provided secret or key pair.
JWTs are signed but not encrypted by default. The payload is base64url-encoded, which is reversible — anyone can decode and read the contents. Never store sensitive data (passwords, credit card numbers) in a JWT payload. Always use HTTPS to prevent token interception during transmission.
JWT is stateless — the server stores nothing; the token itself contains all user information. Sessions store user data server-side and only pass a session ID (usually a cookie) to the client. JWTs scale better horizontally but are harder to revoke. Sessions are easier to invalidate but require shared session storage in distributed systems.
Use a short-lived access token (e.g., 15 minutes) paired with a long-lived refresh token (e.g., 7 days). When the access token expires, the client sends the refresh token to a dedicated endpoint to receive a new access token. The refresh token can be revoked server-side if needed, providing a balance between stateless efficiency and security control.
Common algorithms: HS256 (HMAC with SHA-256, symmetric — same key for sign and verify), RS256 (RSA with SHA-256, asymmetric — private key signs, public key verifies), and ES256 (ECDSA with SHA-256, asymmetric). For production, prefer asymmetric algorithms (RS256/ES256) so the signing key can be kept private while anyone can verify.
Signature verification fails when: the secret or public key does not match the one used to sign, the token has been modified after signing, or the algorithm in the header does not match what the verifier expects. Never use the 'none' algorithm in production — always validate that the algorithm matches your expectations.