100% free · Runs 100% in your browser · No signup needed
A JSON Web Token (JWT) is the compact, URL-safe credential behind most modern authentication: a server signs a small JSON payload, the client sends the token with each request, and the server verifies the signature instead of re-checking a password. Our free JWT Generator is a developer workbench for those tokens — create signed tokens, inspect unknown ones, and verify signatures, all without leaving the page.
The tool has two modes. Encode mode takes a header JSON and a payload JSON (or builds the payload from a simple claim builder) plus your secret, and produces a signed token using real HMAC cryptography via the browser's WebCrypto API — with HMAC-SHA1, SHA-256, SHA-384, and SHA-512 all supported. The header comes pre-filled with {"alg":"HS256","typ":"JWT"}, the most common configuration in the wild, so you can generate your first token in seconds.
Decode mode takes any token you paste and splits it into its three color-coded parts — header, payload, and signature — with each JSON section pretty-printed for easy reading. Paste the matching secret and the tool re-computes the signature to tell you whether the token is genuinely signed by that secret, which is exactly how you debug "invalid signature" errors during development.
One warning is prominent in the tool and worth repeating here: this is a demo and development aid, not a production system — never paste production secrets or real user tokens into it. Everything runs locally in your browser and nothing is transmitted, which makes it perfect for learning and debugging, but production credentials should never leave your own infrastructure, no matter how trustworthy a page looks.
If you have used “sign in with” buttons or called an API with a Bearer token, you have already used JWTs — OAuth2 and OpenID Connect, the standards behind most modern login flows, issue access tokens in exactly this format. That is why being able to generate and inspect them by hand is such a practical skill: when your frontend sends a token and the API rejects it, the answer is almost always visible in the decoded payload or the signature check, not buried in framework logs.
Understanding a token’s anatomy helps everything else click. A JWT is three Base64URL-encoded segments joined by dots: the header (algorithm and token type), the payload (the "claims" — subject, expiry, issuer, and your custom data), and the signature (the HMAC of the first two segments under your secret). Anyone can read the payload — it is only encoded, not encrypted — which is why secrets and sensitive data never belong inside one.
To generate a token:
To decode and verify:
Building the API those tokens will protect? It needs a home. FistHost web hosting starting at just $0.99 per month includes a free domain and fast servers — prototype your auth flow here, deploy the real thing there.
For development and test tokens, yes — everything runs locally in your browser and nothing is sent anywhere. For production secrets or real user tokens: no. Use this as a dev tool only, and keep production credentials inside your own infrastructure.
HMAC-SHA1, HMAC-SHA256, HMAC-SHA384, and HMAC-SHA512, computed with the browser's WebCrypto API. HS256 is pre-selected as the most common choice.
Yes — decoding (reading the header and payload) needs no secret. The secret is only required to verify that the signature is genuine.
The usual causes: a different secret than the one used to sign, a different algorithm, or accidental whitespace copied with the token. Decode the token first and compare the alg claim with your settings.
No. JWT payloads are Base64URL-encoded, which anyone can decode. Never put passwords, personal data, or secrets in a token's claims.
At minimum: sub (who the token is for) and exp (when it expires). iat (issued at) and iss (issuer) are common and useful. Keep custom claims small and non-sensitive.
Technically the signatures are real, but you should not: production token issuance belongs in your own backend with secrets managed securely, not in a browser page. Use this tool for development, testing, and learning.
HS256 uses one shared secret for both signing and verifying — simple, and what this tool supports. RS256 uses a public/private key pair: the server signs with a private key and anyone verifies with the public key. RS256 is better for multi-service setups, but for learning, testing, and single-server apps, HS256 is the pragmatic choice.
This workbench both generates signed tokens and decodes them. The standalone JWT Decoder focuses purely on inspection — use whichever fits your current task.
More free FistHost tools for developers: JWT Decoder for quick token inspection, Password Generator for strong secrets, SHA256 Hash Generator, Base64 Encoder Decoder, and Online MD5 Generator.
Ready to ship the API behind those tokens? FistHost web hosting starting at just $0.99 per month comes with a free domain, one-click installs, and fast, reliable servers — debug your auth here, launch it live today.
No reviews yet. Be the first to review this tool!
Reviews are protected by captcha and moderated before they appear.