All tools
Developer tools

JWT Encoder

Paste a JSON payload and a secret — get a signed HS256 JWT with iat and exp set automatically.

HS256 signing Custom payload Configurable TTL Auto iat + exp
Get started free Sign in

Free · No credit card · 50 credits/day

How token creation works

Four steps, all automatic.

1

Build the header

A fixed header {"alg":"HS256","typ":"JWT"} is Base64url-encoded — the algorithm is always HS256.

2

Inject timestamps

iat (issued at) is set to now. If TTL > 0, exp (expires at) is set to now + TTL seconds.

3

Encode the payload

Your JSON payload (with iat and exp added) is Base64url-encoded to form the second segment.

4

Sign with HMAC-SHA256

HMAC-SHA256(header + "." + payload, secret) produces the signature, Base64url-encoded as the third segment.

Choosing the right TTL

Shorter is safer — pair with refresh tokens for seamless UX.

🔐
5–15 minutes Very short

One-time actions — password resets, email verification, payment confirmation.

✅
15–60 minutes Recommended

Access tokens in a refresh-token architecture. Short enough to limit damage if stolen.

⚠️
1–24 hours Moderate

Internal APIs and tooling where convenience outweighs the longer exposure window.

🚨
0 (no expiry) Avoid

Only for API keys with manual revocation. A stolen non-expiring token is valid forever.

HS256 vs RS256 — which should I use?

HS256 — this tool

Symmetric · shared secret

  • One secret key used to both sign and verify
  • Simpler setup — no key pair needed
  • Both parties must have the secret
  • Good for monoliths and internal APIs

RS256

Asymmetric · public/private key pair

  • Private key signs, public key verifies
  • Third parties can verify without the private key
  • Publish the public key via JWKS endpoint
  • Required for OAuth 2.0 / OIDC / federated identity

Use a strong secret key

A weak HS256 secret can be brute-forced by offline attackers who obtain a signed token. Use at least 32 random characters. Never use common words, passwords or short strings as your JWT secret. Never hardcode the secret in client-side code — it must stay server-side only.

Frequently asked questions

What is a JWT and when should I use one?

A JSON Web Token (JWT) is a compact signed token that carries claims about a user or session. Use JWTs for stateless authentication (no server-side session store needed), API authorization, and passing identity between microservices. The server verifies the signature on each request instead of looking up a session.

What is HS256 and is it secure?

HS256 (HMAC-SHA256) signs the token with a shared secret key. It is secure when the secret is long (32+ characters), random and kept private. The main limitation is that both signer and verifier must share the same secret — making it unsuitable for scenarios where you want external parties to verify tokens without sharing your secret. For those cases, use RS256.

What TTL should I use?

Short-lived tokens (15–60 minutes) are safer — if a token is stolen, it expires quickly. Pair short access tokens with longer-lived refresh tokens: the access token is sent on every request, the refresh token is used only to obtain a new access token.

Where should I store JWTs on the client?

Prefer HttpOnly cookies over localStorage. localStorage is accessible to JavaScript and vulnerable to XSS — a malicious script can steal the token. HttpOnly cookies cannot be read by JavaScript and require CSRF protection instead. For mobile apps, use the platform's secure keystore.

Related developer tools

More tools for tokens, encoding and identifiers.

JWT Decoder

Decode and inspect any JWT — header, payload, timestamps and optional HS256 verification.
UUID Generator

Generate cryptographically secure UUID v4 identifiers — 1 to 50 at once.
Hash Generator

Generate MD5, SHA-256 and SHA-512 hashes from any text.

Create a signed JWT now

Free account. 50 credits per day. Access to 75+ tools instantly.

Create free account →