Free JWT Generator

What a JWT Actually Is

A JSON Web Token (JWT), pronounced "jot", is a compact, URL-safe representation of claims to be transferred between two parties. The format is three Base64url-encoded segments separated by dots: header.payload.signature. The header declares the token type (always JWT) and the signing algorithm (commonly HS256, RS256 or ES256). The payload carries the claims, a JSON object with standard fields like iss (issuer), sub (subject), aud (audience), exp (expiration time as Unix timestamp), nbf (not before), iat (issued at), jti (JWT ID), plus any application-specific claims the issuer wants to include. The signature is the cryptographic proof that the header and payload haven't been tampered with, produced by signing the concatenated base64url(header).base64url(payload) string with the algorithm and key declared in the header. JWT was specified by Michael B. Jones, John Bradley, and Nat Sakimura as RFC 7519 in May 2015, building on prior work in JOSE (JSON Object Signing and Encryption, RFCs 7515 through 7520). The format has become the dominant token shape in modern web authentication, used by OAuth 2.0 / OIDC implementations, API gateways, single-page-app session tokens, microservice-to-microservice authentication, and browser cookie-based session management at scale.

The Signing Algorithm Choice, HS256 vs RS256 vs ES256

JWT supports several signing algorithms registered in the JOSE Algorithms registry (RFC 7518). HS256 (HMAC-SHA256) is the simplest: a symmetric algorithm where the same secret is used to sign and verify. Cheap to compute, easy to implement, and appropriate when the signer and verifier are the same party (e.g., a single application issuing session tokens to itself). RS256 (RSA-SHA256) is asymmetric: the private key signs, the public key verifies. Used when the issuer and verifier are different parties, Auth0, Okta, Google Identity Platform, Microsoft Entra ID, and most cloud identity providers issue RS256-signed JWTs because clients can verify the signature using a published JWKS (JSON Web Key Set) endpoint without needing to share secrets. ES256 (ECDSA P-256 SHA-256) is the elliptic-curve equivalent of RS256, same public/private key model, much shorter keys (256 bits vs RSA's 2048 minimum), faster verification. EdDSA (Ed25519) is the modern successor to ES256, slightly faster and with cleaner cryptographic properties; supported in newer JWT libraries but not yet universal. none is a JWT-spec-permitted "no signature" mode that has caused security incidents across multiple libraries when implementations failed to reject alg: none tokens, the lesson is that JWT verifiers must explicitly check the algorithm matches the expected one. This generator uses HS256 because it requires only a shared secret rather than key generation; for production use of asymmetric algorithms, a server-side library is the right tool.

When You Need to Generate a JWT by Hand

• Testing API endpoints. An API requires a JWT in the Authorization header, to test it manually with curl, Postman, or HTTPie, you need a token. Generate a test JWT with the right shape, sign it with the API's shared secret (in dev environments), and use the result.
• Reproducing a token-related bug. A user reports an authentication issue. Reconstruct the token they would have received with their claims, examine the signature, verify your service's verification logic against a known-good and known-bad token.
• Local development without an auth provider. Building a frontend against an API that expects JWT authentication, but you don't have access to the production identity provider yet. Generate test JWTs with realistic claims for development.
• Learning the JWT format. Decode a JWT, change a claim, re-sign it, see what your application does. The hands-on debugging-by-tinkering loop is how most developers come to understand JWT structure.
• Internal service-to-service tokens. Two internal microservices share a secret and use JWT to authenticate requests. The shared-secret HS256 model is appropriate here; this tool can generate the tokens manually for testing.

Security Pitfalls, Where JWTs Go Wrong

JWTs have a long history of implementation mistakes that have produced real security incidents. The "alg: none" attack: early JWT libraries accepted tokens with the algorithm field set to "none" (no signature), letting an attacker forge any token. Verifiers must explicitly enforce the expected algorithm. Algorithm confusion: a verifier that accepts both RS256 and HS256 can be tricked by using the public RSA key as the HMAC secret, the attacker signs with HS256 using the public key, the verifier (mis-)verifies with HMAC using the same public key. Verifiers must pin the expected algorithm. Sensitive data in payload: JWT claims are Base64-encoded but not encrypted. Anyone with the token can read every claim. Never put passwords, full credit-card numbers, or other secrets in the payload. No expiration: JWTs without an exp claim are valid forever. Always set a reasonable expiration (minutes for access tokens, days for refresh tokens). No revocation: JWTs are self-contained, once issued, they remain valid until exp regardless of whether the user logs out, changes password, or has their account suspended. Either accept this limitation, or maintain a revocation list (which partially defeats the stateless-token point), or use short-lived access tokens with refresh-token rotation. Storing in localStorage vs cookies: JWT in localStorage is accessible to any JavaScript running on the page (XSS risk); JWT in HttpOnly cookies is not (but is sent automatically with cross-origin requests, CSRF risk). Both have trade-offs; modern best practice tends toward HttpOnly cookies with SameSite restrictions plus CSRF tokens.

JWT vs Session Cookies vs PASETO

JWT isn't the only choice. Traditional session cookies store an opaque session ID; the server keeps the actual session state in a database or cache. Pros: trivial revocation (delete the server-side record), no risk of leaking claim data, no signature complexity. Cons: requires session store lookup on every request (latency), harder to scale across services. PASETO (Platform-Agnostic Security Tokens, Scott Arciszewski 2018) is a JWT-replacement designed to avoid the algorithm-confusion and "none" pitfalls, versioned format, no algorithm negotiation, mandatory signatures, restricted cipher choices. PASETO has gained traction in security-sensitive contexts but hasn't displaced JWT in the broader ecosystem. Macaroons (Google, 2014) are a more flexible token format with chained capability restrictions but are essentially research-only in 2026. OAuth 2.1 consolidates the OAuth 2.0 best practices, JWT is still the typical access-token format. The pragmatic choice in 2026 remains JWT for stateless microservices and API tokens, opaque session cookies for traditional server-rendered web apps, with PASETO as the modern alternative for new greenfield projects that want stronger defaults.

Frequently Asked Questions

Can I decode a JWT without the secret?

Yes. The header and payload sections of a JWT are only Base64url-encoded, not encrypted. You can read all claims without the secret. The secret is only needed to verify that the signature is valid (i.e., that the token was not tampered with).

Is it safe to paste production JWTs here?

Yes. This tool runs entirely in your browser, no data is sent to any server. Your tokens and secrets are processed only in your local JavaScript environment and are never logged or transmitted.

What is the difference between HS256, RS256, and ES256?

HS256 uses a shared HMAC secret (symmetric). RS256 and ES256 use public/private key pairs (asymmetric), the private key signs the token, and the public key verifies it. This tool supports HMAC algorithms; for RS256/ES256 verification use a server-side library.