See every header, claim, and signature in a readable format. Verify expiration, issuer, algorithm, and more in one place.
JSON Web Tokens (JWTs) are compact, URL-safe tokens used for authentication and authorization in modern web applications. A JWT contains encoded information about a user or system, cryptographically signed to prevent tampering. Validation ensures the token is authentic, hasn't expired, and comes from a trusted source.
JWTs are commonly used in OAuth 2.0 and OpenID Connect flows for secure API authentication and single sign-on (SSO) systems.
Note: All validation happens client-side in your browser.
This validator supports the following asymmetric signing algorithms for signature verification:
Note: HMAC algorithms (HS256, HS384, HS512) require shared secrets and cannot be verified with public keys.
JWT validation is critical for security in applications using token-based authentication. Validation prevents:
exp claim prevents accepting stale tokensiss) and, when present, the audience (aud) ensures tokens come from trusted sourcesnbf (not before) and jti (JWT ID) adds additional security layersYes. All decoding and validation happens entirely in your browser using the Web Crypto API. No data is sent to any server. Your token never leaves your machine.
The payload of a JWT is only base64url-encoded, not encrypted, so anyone can decode and read it. However, the signature binds the header and payload together cryptographically. If any part of the token is modified, signature verification will fail. This is why verifying the signature is critical since decoding alone does not confirm the token is trustworthy.
A JWT without an exp claim never expires on its own. This is a security risk. If the token is stolen or leaked, it remains valid indefinitely. Best practice is to always include an exp claim and keep the lifetime short, relying on refresh tokens for long-lived sessions.
A JWT (JSON Web Token) is a claim set encoded as a JSON object. A JWS (JSON Web Signature) is the mechanism that signs and wraps that payload. In practice, most JWTs you encounter are JWS tokens. The three-part dot-separated format is defined by JWS. JWT defines what goes in the payload; JWS defines how it gets signed and serialized.
A JWK (JSON Web Key) is a JSON object that represents a cryptographic key. A PEM file is a base64-encoded format wrapped in header and footer lines like -----BEGIN PUBLIC KEY-----. Both can represent the same underlying key. JWK is more common in modern auth systems and APIs, while PEM is more common in traditional server infrastructure. This tool accepts both formats for signature verification.
Most authorization servers expose a JWKS endpoint, typically at /.well-known/jwks.json, though some provide a dedicated API endpoint instead. This endpoint returns the public keys used to sign tokens. Find the key whose kid matches the kid in your JWT header, copy the full JWK object, and paste it into the Signature Verification section above. If you control the signing server, you can also export the public key directly in PEM format.
kid claim mean?The kid (key ID) claim is an optional header parameter that identifies which key was used to sign the JWT. When an authorization server rotates keys, the kid tells the verifier which public key from the JWKS endpoint to use for verification. If your JWT has a kid, look it up in your auth server's JWKS endpoint to get the correct public key.
The following standards and resources are relevant to JWT validation, security, and token-based authentication: