Online JWT Parser / Generator / Verifier

Online JWT Parser / Generator / Verifier

JWT (JSON Web Token) consists of three parts: Header, Payload, and Signature, separated by two dots. It is widely used for API authentication, single sign-on, and stateless sessions. This tool puts parsing, generation, and verification on the same page with three tabs. Parsing does not require a key, while generation and verification require a Secret or key.

Parse a Token

Paste a Token and it is automatically split into three parts. Header and Payload are decoded from Base64URL and formatted as JSON, while Signature is preserved as-is. Each part can be copied separately. The page also reads header fields such as alg, typ, and kid, recognizes standard claims such as iss, sub, aud, and jti, and converts the iat, nbf, and exp timestamps to local time.

Token Status and Time Information

Based on the time claims, the tool automatically determines the overall Token status: valid, expiring soon, expired, not yet active, or no time claims. It also shows the remaining time until expiration. This makes it easier to troubleshoot authentication state issues by distinguishing an expired Token, a Token that has not become active yet, and a signature problem. Custom claims can be viewed directly in the Payload JSON.

Generate a Token

The generation tab lets you edit the Header and Payload JSON directly, with buttons for formatting and minifying the JSON. Common claims can also be inserted with one click, with exp defaulting to the current time plus one hour. Select an algorithm and provide the corresponding key to issue a Token. HMAC algorithms use a Secret, which can be processed as UTF-8 text or parsed as hexadecimal when prefixed with 0x. RSA and EC algorithms accept a PEM private key or JWK. Invalid JSON is reported immediately.

Supported Algorithms

A total of 12 algorithms are supported: HS256, HS384, HS512, RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, and ES512. The HS series uses HMAC signatures, the RS and PS series are based on RSA, and the ES series is based on ECDSA. The page indicates algorithms that require a secure context.

Verify a Token

Verification requires the public key corresponding to the signature. RSA accepts SPKI or PKCS#1 public key PEM or JWK, while EC accepts SPKI public key PEM or JWK. The verification result separately shows whether the signature is valid, whether the Token has expired, and whether it is active, with specific reasons provided for failures. If a private key is pasted, the page prompts you to use the corresponding public key instead.

Error Handling and Security Constraints

• Insufficient Token segments, invalid Base64URL data, and corrupted JSON are reported separately.
• For security reasons, unsigned Tokens with alg set to none are always rejected during verification.
• If the algorithm declared by the Token does not match the currently selected algorithm, the tool clearly identifies both algorithms.
• If an ECDSA signature has an incorrect length, the tool explains that JWS uses a fixed-length raw concatenation of R and S, and DER signatures from openssl must be converted first.
• Empty, malformed, or password-encrypted keys produce corresponding handling recommendations.

Runtime Environment

The RS, PS, and ES series rely on the WebCrypto interface provided by the browser. WebCrypto is available only in a secure context, so HTTPS is required. The HS series is not affected and can also generate and verify Tokens over HTTP.

Use Cases

• Debug API authentication: confirm that the Token issued by the backend contains the expected data and expiration time.
• Troubleshoot 401 errors: distinguish between an expired Token, a Token that is not yet active, and a signature mismatch.
• Issue local test Tokens to simulate different roles or permission claims.
• Check whether keys are correctly paired and whether the selected signature algorithm is consistent.

Privacy and Data Security

Tokens, Secrets, private keys, and public keys are all processed locally in the browser. There is no server-side computation interface, and input data is not uploaded or saved. Note that the JWT Payload is Base64URL encoded rather than encrypted, so anyone who obtains the Token can read its contents. Do not put sensitive information in the Payload.