Your files never leave your device. All processing happens locally in your browser.
How do I create, sign, decode and verify a JWT online?
Edit the header and the payload claims, choose a signing algorithm — HS256/384/512 with a shared secret, or RS256, PS256, ES256/384 or EdDSA with a key pair — and this tool signs a real JSON Web Token you can copy. Switch to Decode to pretty-print any token, or Verify to check its signature and standard claims. Everything runs in your browser via the jose library; no token or key is uploaded.
Sign real JWTs with HMAC (HS256/384/512) or a key pair (RS256, PS256, ES256/384, EdDSA)
Editable header and payload with helpers for iss, sub, aud, exp, nbf, iat and jti
Decode any token to readable JSON with live exp/iat/nbf and an expired / not-yet-valid badge
Verify the signature and claims with your secret or public key
Generate a key pair (PEM) locally — nothing is uploaded
What is
JWT (JSON Web Token)
A JSON Web Token (RFC 7519) is a compact, URL-safe string of three base64url parts — header, payload and signature — joined by dots. The header names the algorithm, the payload carries claims such as issuer, subject, audience and expiry, and the signature (a JWS, RFC 7515) lets a recipient confirm the token came from a holder of the secret or private key and was not altered. The payload is only ENCODED, not encrypted, so anyone can read it.
No. A standard signed JWT is only base64url-encoded, so anyone who has the token can read the payload — never put passwords, keys or personal secrets in it.
A signed JWT (JWS) protects INTEGRITY, not confidentiality: the header and payload are merely base64url-encoded and are trivially decoded by anyone holding the token, as this tool’s Decode tab shows without any key. The signature only proves the token was issued by someone with the secret or private key and has not been tampered with. So never place secrets, passwords or sensitive personal data in the payload; if you need the contents hidden, use encrypted tokens (JWE) or send the token only over TLS and keep it short-lived, storing just an opaque reference server-side when in doubt.
No. Signing, decoding and verification all run locally in your browser via the jose library; nothing is sent to a server.
This tool is 100% client-side. The jose library signs and verifies in the browser using the Web Crypto API, key-pair generation uses crypto.getRandomValues, and there is no server, upload, CDN in the crypto path or telemetry. Your payload, secret and private key are just values in memory and are gone when you close the tab. Even so, treat production signing keys carefully — prefer to mint real tokens on your server, and use this for building, decoding and debugging.
Use HS256 (HMAC) when one trusted party both signs and verifies with a shared secret; use RS256/ES256/EdDSA when others must verify with only a public key.
HMAC algorithms (HS256/384/512) sign and verify with the SAME shared secret — simple, but every verifier must be trusted with that secret. Asymmetric algorithms sign with a private key and let anyone verify with the public key: RS256 (RSA) is the most widely supported, while ES256 (ECDSA P-256) and EdDSA (Ed25519) give comparable security with much smaller signatures. Use an asymmetric algorithm whenever a different service must verify tokens you issue, use a long random secret (32+ bytes) for HMAC, and keep private keys safe.
alg:none is a token that claims to need no signature; algorithm confusion tricks a server into verifying an RS256 token as HS256 using the public key as the HMAC secret. Reject both by pinning the expected algorithm.
Two classic JWT pitfalls: (1) alg:none — a forged token whose header says no signature is required, which a safe verifier must never accept. (2) Algorithm confusion — if a server verifies using whatever algorithm the header names, an attacker can take a public RSA key, craft an HS256 token and sign it with that public key as the HMAC secret, and a naive verifier accepts it. The fix for both is to PIN the expected algorithm(s) when verifying and never let the token dictate them; this tool verifies against a chosen algorithm so you can see the check in action.
Detailed Explanation
📖How It Works
What the JWT Creator Does
This tool creates, signs, decodes and verifies JSON Web Tokens (RFC 7519) entirely in the browser using the jose library over the Web Crypto API. A JWT is three base64url segments — header, payload and signature — joined by dots; the header names the algorithm, the payload holds claims (issuer, subject, audience, expiry and any custom data), and the signature (a JWS, RFC 7515) proves the token was issued by a holder of the key and was not altered. The payload is only encoded, not encrypted.
Sign, decode and verify JWTs locally via jose + Web Crypto
HMAC (HS256/384/512) and asymmetric (RS/PS/ES/EdDSA) algorithms
The payload is base64url-encoded, not encrypted — readable by anyone
100% client-side; no token or key is uploaded
⚙️Methodology
Signing, Decoding and Verifying
In Create mode you edit the header and the payload as JSON, with one-tap helpers for the registered claims (iss, sub, aud, exp via a duration picker, nbf, iat, jti). Choose an algorithm: HMAC uses a shared secret (entered as text or base64), while RS/PS/ES/EdDSA use a PEM private key you paste or a key pair you generate in-browser. The token is signed live. Decode mode splits any pasted token and pretty-prints the header and payload, rendering exp/iat/nbf as human dates with expired or not-yet-valid badges. Verify mode checks the signature and the standard claims against your secret or public key, with the expected algorithm pinned.
HMAC secret (text/base64) or PEM key pair (paste or generate)
Decode shows readable exp/iat/nbf with validity badges
Verify pins the algorithm so the token cannot dictate it
Copy the token, the header or the payload
🔧Technical Details
JWT Security: alg:none and Algorithm Confusion
Two well-known JWT attacks shape safe usage. alg:none is a token whose header claims no signature is needed; a correct verifier must reject it outright. Algorithm confusion abuses verifiers that trust the header’s alg: given a public RSA key, an attacker forges an HS256 token signed with that public key as the HMAC secret, and a naive RS256 verifier that reuses the public key accepts it. The defence for both is to PIN the algorithm(s) you expect at verification time and never let the incoming token choose. Prefer asymmetric signatures when a different service verifies your tokens, use a 32-byte-plus random HMAC secret, and keep tokens short-lived.
Reject alg:none — never accept an unsigned token
Pin the expected algorithm(s) when verifying (defeats HS/RS confusion)
Use asymmetric (RS/ES/EdDSA) when others verify with a public key
HMAC secrets should be long and random (32+ bytes)
Keep tokens short-lived and send them only over TLS
⚠️Limitations
Honest Limitations
This is a build, debug and learning tool, not your auth server. A signed JWT hides nothing — the payload is world-readable — so never put secrets in it; for confidentiality use encrypted JWE or an opaque server-side reference. Real tokens should be minted server-side with keys that never touch a browser; treat any key you paste here as compromised for production use. The tool signs and verifies exactly what you give it, but it does not manage key rotation, revocation, audience allow-lists or clock-skew policy for you — those belong in your backend. Never paste a real production signing key or a live user token into any online tool.
A build/debug aid — mint real tokens server-side
The payload is not secret; use JWE for confidentiality
Keys pasted here should not be your production private keys
Revocation, rotation and audience policy live in your backend
Never paste live production keys or user tokens anywhere online
🔒Privacy & Security
Private by Design
Everything happens on your device. jose signs, decodes and verifies in the browser through the Web Crypto API, and key-pair generation draws from crypto.getRandomValues — never Math.random. Your payload, secret and keys are values in memory only: there is no network request, no upload, no logging, no server and no CDN anywhere in the crypto path. Nothing is persisted or added to history, so closing the tab erases it. The tool works offline once cached, supports dark mode and a mobile-first layout, and has no analytics. The only optional network use anywhere on the site is consent-gated ads, which never see your token or key.
Signed/verified locally via jose + Web Crypto; keys from crypto.getRandomValues
No server, no CDN, no upload, no logging, no telemetry
Nothing persisted — closing the tab erases the token and keys
Works offline once cached; dark-mode and mobile-first
Only optional network use is consent-gated ads that never see your data
JWT signing algorithms compared
Algorithm
Type
Keys
Notes
HS256/384/512
HMAC (symmetric)
One shared secret
Simple; every verifier must be trusted with the secret
RS256 / RS384
RSA signature
Private signs, public verifies
Most widely supported asymmetric option; larger tokens
PS256
RSA-PSS
Private / public
Modern RSA padding; preferred over RS where supported
ES256 / ES384
ECDSA
Private / public
Small signatures, same security as RSA; widely supported
EdDSA (Ed25519)
Edwards-curve
Private / public
Fast, compact, modern; use where supported
none
Unsigned
None
NEVER accept — a forged, unsigned token
Use HMAC when one party signs and verifies; use RS/PS/ES/EdDSA when others verify with a public key. Always pin the expected algorithm on verification and reject alg:none. Everything in this tool runs locally in the browser. As of July 2026.
