Decode the token. Verify it without leaking the key.
Read the header and every claim of a JSON Web Token, watch exp count down, and check the signature with your own secret or public key — all inside your browser, with nothing sent to a server.
JSON Web Token
A leading "Bearer " is detected and removed automatically, along with line breaks. Decoding happens as you type.
Token structure
—■ header ■ payload ■ signature
Verify signature
—For HS* paste the exact shared secret. For RS*, PS* and ES* paste the PEM public key (SPKI), for example the output of openssl pkey -pubout.
Decoded header
—
Decoded payload
—
Claims and timestamps
Paste a token to see its claims explained.
Signature bytes
—Paste a token to see its claims explained.
Decoding a JWT proves nothing. Verifying proves one thing.
A JWT is three base64url segments joined by dots. The first two — header and payload — are not encrypted. They are merely encoded, so anyone holding the token can read every claim: user id, roles, e-mail, tenant, expiry. If you would not print a value in a log line, it does not belong in a JWT payload. The third segment is the signature, and it is the only part that carries security weight.
Verification answers exactly one question: did whoever holds the key produce this exact header and payload? It says nothing about whether the claims are true, whether the issuer is the one you trust, or whether the key belongs to the right party. A token signed correctly by the wrong service is still a valid signature over a payload you must reject.
What the standard claims mean
iss (issuer) must match the authority you expect, compared exactly — not by substring. aud (audience) must contain your service; a token minted for a different API should be rejected even with a perfect signature. exp and nbf are NumericDate values in seconds, not milliseconds, and a small clock skew allowance (often 60 seconds) is normal. sub identifies the subject, and jti is a unique id that only helps if your server actually keeps a revocation list. scope and azp are OAuth 2.0 fields: the granted permissions and the client that asked for the token.
Which signatures can be checked in a browser
WebCrypto covers the algorithms that matter in practice. HS256/384/512 use HMAC with the shared secret, which is fine for a quick check but means every service that verifies can also mint tokens. RS256/384/512 use RSASSA-PKCS1-v1_5 with an SPKI public key. PS256 is the same RSA key with PSS padding and a 32-byte salt. ES256 and ES384 use ECDSA over P-256 and P-384. Paste the secret or the public key — never a private key, and never a key you do not own.
ECDSA: the raw and DER encodings
JOSE stores an ECDSA signature as the raw concatenation of two big integers, r followed by s, which is 64 bytes for P-256 and 96 for P-384. Classic libraries such as OpenSSL expect the DER structure instead. WebCrypto follows the raw IEEE P1363 form, so JWT signatures normally verify directly — but a few engines differ, so this tool retries with a raw-to-DER conversion and tells you when that was what made it pass, rather than showing a false "invalid".
alg:none and algorithm confusion
A token with "alg":"none" has no signature. Some libraries historically accepted it, which let an attacker rewrite the payload and keep "valid". The related bug is algorithm confusion: taking an RS256 token, declaring it HS256 and signing it with the public key as if it were an HMAC secret. Both are prevented by the same rule — the verifier must pin the acceptable algorithms and never take the algorithm from the token itself without checking it against a whitelist.
Frequently Asked Questions
Is it safe to paste my secret into this page?
The secret stays in your browser: payload decoding uses atob and TextDecoder, and the signature is checked with crypto.subtle. No network request carries it, and there is no server to log it. That is deliberate — shared secrets should never be sent to an online verifier, because then the tool becomes the leak.
A valid signature is shown — can I trust the token now?
You have proven integrity since signing, and nothing else. Still check iss, aud, exp and the algorithm, and confirm the key you pasted belongs to the issuer you expect. Signature validity is a necessary condition, not a sufficient one.
Why does my token show "invalid" when the server accepts it?
The usual causes are a secret with a trailing newline, a public key in PKCS#1 format instead of SPKI, an ES signature in a non-standard encoding, or a token that was actually re-encoded by a proxy (any change to the base64url text invalidates the signature). Check the human-readable error above the result — it names the failing step.
Can I decode an encrypted token?
Not here. An encrypted JWE has five segments, and its payload is ciphertext: without the decryption key there is nothing to read. A three-segment JWT is a JWS, signed rather than encrypted, which is why the claims are visible to everyone.
Does the tool send anything to analytics?
The page loads the same Google Analytics tag as the rest of the site, which records the visit. The token text itself is never placed in the DOM in a form that is reported, never copied into a URL, and never posted anywhere by this tool.
Related tools
Cron expression builder and parser · WCAG contrast checker · All MousyTools
Hecho por MousyDev
Creo herramientas web que respetan tu privacidad: tus datos se procesan en tu propio navegador y nunca pasan por mis servidores.