Does the JWT Validator send my token or secret to a server?

No. All validation — signature verification, claim checking, and decoding — happens entirely in your browser. Your JWT token and secret never leave your device, are never sent to any server, and are not stored anywhere. This makes the tool safe to use even with sensitive tokens during development.

What JWT algorithms does the validator support?

The JWT Validator supports HMAC-based algorithms: HS256 (HMAC with SHA-256), HS384 (HMAC with SHA-384), and HS512 (HMAC with SHA-512). These are the most common algorithms used for symmetric JWT signing. RSA (RS256/384/512) and ECDSA (ES256/384/512) support is not included because asymmetric verification requires parsing public keys in PEM/JWK format, which is beyond the scope of this tool.

How does signature verification work?

The validator takes the base64url-encoded header and payload segments (the "signing input"), computes an HMAC using the provided secret and the algorithm specified in the token header, and compares the computed signature to the signature segment of the token. This uses the browser's native Web Crypto API (crypto.subtle.verify) for real cryptographic verification — not a simplified comparison.

What is the difference between JWT decoding and JWT validation?

Decoding a JWT simply reverses the base64url encoding on the header and payload to make them readable — anyone can do this, no secret needed. Validation (or verification) means cryptographically proving that the signature was created with the correct secret, ensuring the token has not been tampered with, and checking that claims like expiration and not-before are satisfied. Decoding tells you what the token says; validation tells you whether you can trust it.

What happens if my token is expired?

If you enable the "Check Expiry" option and your token's exp claim is in the past, the validator will mark the token as invalid and show an error explaining that the token has expired, along with the expiration timestamp. If you disable the expiry check, the validator will still verify the signature but will not flag the token as expired — useful for inspecting old tokens.

Why should I restrict allowed algorithms?

Restricting the allowed algorithms is a critical security practice. Without an allow-list, an attacker could potentially craft a token with a different algorithm — such as "none" (no signature) or a weaker hash — and bypass verification. By specifying only the algorithm(s) your application uses, you ensure that tokens signed with any other algorithm are rejected, even if the attacker knows the secret.

🛠️DevToolsHub

JWT Validator

Validate JWT tokens by verifying signatures and checking claims.

What is JWT Validation?

JWT Validationis the process of cryptographically verifying that a JSON Web Token (JWT) has not been tampered with since it was issued. Unlike simply decoding a JWT — which anyone can do because the header and payload are only base64url-encoded — validation requires the secret key (for HMAC algorithms like HS256, HS384, HS512) or public key (for RSA or ECDSA algorithms) that was used to sign the token. The validator re-computes the signature over the header and payload and compares it to the signature in the token. If they match, the token is authentic; if they don’t, the token has been modified or forged.

Validation goes beyond signature verification. A complete validation also checks the token’s claims — the statements encoded in the payload. The most critical claim checks are exp (expiration time), which ensures the token has not expired, and nbf (not before), which ensures the token is not being used before its intended valid-from time. Additional checks may include verifying the iss (issuer) and aud (audience) claims to ensure the token was issued by the expected party and is being used by the intended recipient.

DevToolsHub’s JWT Validator performs all of these checks in your browser using the Web Crypto API for real cryptographic signature verification. It supports the three HMAC algorithms defined in RFC 7519 — HS256, HS384, and HS512 — and provides clear, detailed feedback about each validation step so you know exactly what passed and what failed.

How to Use

Paste your JWT token into the token input area. The tool shows a live decoded preview as you type, so you can see the header and payload before validating.
Enter the secret used to sign the token. For HMAC algorithms (HS256, HS384, HS512), this is the shared secret or signing key. The field supports show/hide toggling for convenience.
Configure validation options — toggle expiry checking, not-before checking, and select which algorithms to allow. By default, all three HMAC algorithms are permitted.
Click Validate to run the full verification. The tool verifies the signature using the Web Crypto API, checks the selected claims, and displays the results.
Review the results — a green banner means the token is valid; a red banner lists all validation errors. Individual check cards show pass/fail status for signature, algorithm, expiry, and not-before checks.
Inspect the decoded header and payload in the tabbed output, with copy buttons for easy export. If you only need to decode without verification, use the link to our JWT Decoder tool.

Validation Checks Explained

Signature Verification

The signature is the cryptographic heart of JWT security. The validator takes the base64url-encoded header and payload (the “signing input”), computes the HMAC using the provided secret and the algorithm specified in the header, and compares the result to the token’s signature segment. If they match, the token has not been modified. If they differ, the token is either corrupted or has been tampered with by an attacker. This check uses the browser’s native Web Crypto API (crypto.subtle.verify) for real cryptographic verification — not a simplified reimplementation.

Expiry Check (exp)

The exp claim specifies the Unix timestamp (in seconds) after which the token should no longer be accepted. The validator compares this to the current time and flags the token as expired if the current time is at or past the expiration value. Most APIs reject expired tokens, so this check helps you quickly identify tokens that need to be refreshed.

Not-Before Check (nbf)

The nbf claim specifies the Unix timestamp before which the token should not be accepted. This is useful for tokens that are issued in advance but should only become valid at a specific time (for example, a token issued during a scheduled maintenance window that becomes valid when the window starts). The validator flags the token as not-yet-valid if the current time is before the nbf value.

Algorithm Allow-List

The validator lets you restrict which algorithms are accepted. This is a critical security measure: without an allow-list, an attacker could potentially craft a token with a weaker algorithm (such as none) and bypass verification. By default, the tool accepts HS256, HS384, and HS512, but you can narrow the list to match your application’s expected algorithm.

Security Best Practices

Always validate tokens on your backend. Client-side validation is useful for debugging and education, but your server must independently verify every token it receives. Never rely on client-side validation for security decisions.
Use a strong secret. HMAC security depends entirely on the secrecy and strength of the signing key. Use a long, random, high-entropy secret — at least 256 bits (32 bytes). Never hardcode secrets in client-side code or commit them to version control.
Pin the algorithm.Always specify the expected algorithm(s) when validating tokens. Do not trust the algorithm in the token header — an attacker can change it. The “alg: none” attack is a classic JWT vulnerability where an attacker removes the signature and sets the algorithm to “none”, bypassing verification.
Check all relevant claims. In addition to signature, expiry, and not-before, your backend should verify the issuer (iss), audience (aud), and any application-specific claims that matter for authorization.
Treat JWTs as bearer tokens. Whoever holds a valid JWT can use it. Always transmit tokens over HTTPS, never log them, never expose them in URLs, and use short expiration times with refresh token flows for long-lived sessions.
Use this tool for development only. Our JWT Validator runs entirely in your browser for privacy and speed. It is designed for developers to test and debug tokens during development — not for production authentication.

Frequently Asked Questions

JWT Validator

Validate JWT tokens by verifying signatures and checking claims.

What is JWT Validation?

How to Use

Paste your JWT token into the token input area. The tool shows a live decoded preview as you type, so you can see the header and payload before validating.
Enter the secret used to sign the token. For HMAC algorithms (HS256, HS384, HS512), this is the shared secret or signing key. The field supports show/hide toggling for convenience.
Configure validation options — toggle expiry checking, not-before checking, and select which algorithms to allow. By default, all three HMAC algorithms are permitted.
Click Validate to run the full verification. The tool verifies the signature using the Web Crypto API, checks the selected claims, and displays the results.
Review the results — a green banner means the token is valid; a red banner lists all validation errors. Individual check cards show pass/fail status for signature, algorithm, expiry, and not-before checks.
Inspect the decoded header and payload in the tabbed output, with copy buttons for easy export. If you only need to decode without verification, use the link to our JWT Decoder tool.

Validation Checks Explained

Signature Verification

Expiry Check (exp)

Not-Before Check (nbf)

Algorithm Allow-List

Security Best Practices

Always validate tokens on your backend. Client-side validation is useful for debugging and education, but your server must independently verify every token it receives. Never rely on client-side validation for security decisions.
Use a strong secret. HMAC security depends entirely on the secrecy and strength of the signing key. Use a long, random, high-entropy secret — at least 256 bits (32 bytes). Never hardcode secrets in client-side code or commit them to version control.
Pin the algorithm.Always specify the expected algorithm(s) when validating tokens. Do not trust the algorithm in the token header — an attacker can change it. The “alg: none” attack is a classic JWT vulnerability where an attacker removes the signature and sets the algorithm to “none”, bypassing verification.
Check all relevant claims. In addition to signature, expiry, and not-before, your backend should verify the issuer (iss), audience (aud), and any application-specific claims that matter for authorization.
Treat JWTs as bearer tokens. Whoever holds a valid JWT can use it. Always transmit tokens over HTTPS, never log them, never expose them in URLs, and use short expiration times with refresh token flows for long-lived sessions.
Use this tool for development only. Our JWT Validator runs entirely in your browser for privacy and speed. It is designed for developers to test and debug tokens during development — not for production authentication.