Paste a token to inspect it or supply a payload and test secret to generate one. A valid signature does not replace issuer, audience and authorization checks.
Runs locally in your browserInspect a token to view its header.
Inspect a token to view its payload.
The secret is used only by your browser's cryptography API. This verifier supports HS256, HS384, and HS512; it does not send the token or secret to VoriTools.
Generate only HS256, HS384, or HS512 tokens. The payload and secret stay in your browser's Web Crypto API; this tool never offers alg: none.
Generate a local HMAC JWT to view it here.
Decoded claims are readable Base64URL data, not proof that a token is trusted. Check its algorithm, expiry, intended issuer and audience, then verify its signature with a trusted key or secret before accepting it in an application.
This page splits a compact JWT into its header, payload and signature, prints the decoded claims, and verifies the signature when the token is HMAC-signed and you supply the secret. It also generates short-lived HS256, HS384 or HS512 tokens from a payload you type.
Decoding and verification are deliberately separate steps. Anyone can read the payload of a JWT without a key, and a valid signature only proves that the token was signed with that key. It says nothing about whether the token has expired, was issued for your service, or is allowed to do anything.
The header is Base64URL-encoded JSON that normally declares alg and typ, and sometimes a kid that tells the verifier which key to use. The payload is the claim set: registered claims such as iss, sub, aud, exp, nbf, iat and jti, plus whatever private claims the issuer adds. The signature is the algorithm applied to the ASCII string base64url(header) + "." + base64url(payload) using the key.
Base64URL is the standard Base64 alphabet with + and / replaced by - and _, and with padding removed. That is why a token can be carried in a URL, a cookie or an Authorization header without escaping, and also why reassembling a token by hand usually breaks the signature.
Only the HMAC family, HS256, HS384 and HS512, because a shared secret is enough to recompute them. RS256, PS256, ES256 and EdDSA use a private key to sign and a public key to verify, so they can be decoded here but not verified; you need the issuer's public JWK for that.
A token that declares alg as none must always be rejected, and a verifier should never accept the algorithm named in the token without checking it against an allow-list. Substituting HS256 for RS256 and signing with the public key as if it were an HMAC secret is a well-known attack against careless libraries.
exp must be in the future and nbf in the past, both measured in seconds since the Unix epoch, with a little clock skew allowed between machines. iat should be plausible rather than in the future. iss and aud must match your own service, otherwise a token minted for a different application will be accepted.
A signature check alone is not authorization. Roles, scopes and tenant identifiers live in private claims, and the jwt claim set is signed but not encrypted, so never put a secret in a payload you would not show to the user holding the token.
Accepts a compact JWT (header.payload.signature), HMAC secret, payload JSON, expiration minutes, and HS256/384/512 algorithm; outputs decoded header/payload, signature verification, and generated JWT.
Verify a received JWT signature and claims before accepting it in an application; generate short-lived test tokens for local services; inspect token expiration, issuer, and audience during debugging.
The compact JWT (header.payload.signature), HMAC secret, payload JSON, expiration minutes, and algorithm selection are processed by browser JavaScript using the Web Crypto API; they are not uploaded to VoriTools.
Supports only HS256, HS384, and HS512 HMAC algorithms; it cannot verify or generate RS256/ES256 tokens and never offers the insecure alg: none.
Decoding and HMAC verification run entirely in your browser, so the token is not uploaded. Even so, the safe habit is to test with throwaway tokens: a production refresh token or a long-lived credential should never be pasted into any web page, including this one.
Those algorithms are asymmetric, and this page only recomputes HMAC signatures. The token can still be decoded and its claims read, but verifying it needs the issuer's public key and a library that supports JWA, which a browser page holding only a shared secret cannot do correctly.
Either the secret is wrong, or the algorithm selected does not match the one in the header, or the token text changed after signing. Editing or pretty-printing the payload and re-encoding it by hand produces the same result, because the signature covers the exact original bytes.
Because a JWT is signed, not encrypted. Base64URL is an encoding, and anyone who holds the token can decode the header and payload with no key at all. If the claims themselves are sensitive, use JWE, which encrypts the content for a recipient.
JWT is the claim set, the data. JWS is the signed serialization that produces the compact three-part token this page inspects. JWE is the encrypted serialization, where the payload is unreadable without a key and the structure has five parts instead of three.
Minutes rather than hours. Set Expires in minutes to a small value so a leaked test token stops working, and remember that this page signs with the secret you typed locally, so the token is only valid for systems that share that secret.