JWT Encoder
Create and encode JSON Web Tokens (JWT) with custom header, payload, and secret key. Perfect for developers testing JWT implementation.
Security Notice
This is a demo tool for learning purposes. Never use weak secrets or expose sensitive information in production JWTs.
JWT Configuration
Generated JWT Token
No JWT Generated Yet
Configure your payload and secret, then click "Encode JWT" to generate a token
JWT Standard Claims Reference
Registered Claims
isssubaudjtiTime-based Claims
iatexpnbfTips
- • All claims are optional, but
expis highly recommended for security - • Time claims use Unix timestamps (seconds since epoch)
- • You can add custom claims alongside standard ones
- • Use the
+iatand+expbuttons for quick timestamp insertion
About JWT Encoder
A comprehensive JWT (JSON Web Token) encoder that allows you to create, customize, and generate valid JWT tokens with custom headers, payloads, and secret keys. This tool supports multiple signing algorithms and provides real-time token generation for development and testing purposes.
Why use a JWT Encoder?
Creating JWT tokens manually for testing authentication flows, API development, or integration testing can be time-consuming and error-prone. This encoder streamlines the process by providing an intuitive interface to generate properly formatted and signed JWT tokens, ensuring your authentication testing is both efficient and accurate.
Who is it for?
Essential for backend developers, API engineers, QA testers, and security professionals who need to generate JWT tokens for testing authentication systems. Perfect for developers learning JWT implementation or experienced teams who need quick token generation for development and testing workflows.
How to use the tool
Configure the JWT header with your desired algorithm (HS256, RS256, etc.)
Add custom claims and data to the payload section
Enter your secret key or private key for token signing
Click generate to create your encoded JWT token
Copy the generated token for use in your applications or API testing tools
Frequently Asked Questions
How do I sign a JWT?
Define the header (algorithm, key ID) and the payload (claims like sub, iat, exp, plus custom claims), choose the signing algorithm (HS256 for shared-secret, RS256/ES256/EdDSA for asymmetric), provide the key (raw string for HS*, PEM-encoded private key for RS*/ES*/EdDSA), and the tool produces the signed JWT — three base64url parts separated by dots. The signature is computed over base64url(header) + '.' + base64url(payload). For HS256 the signature is HMAC-SHA256 of that string with your secret; for RS256 it's RSA-PKCS#1 v1.5 over the SHA-256 hash; for ES256 it's ECDSA over SHA-256. The output is byte-for-byte compatible with any standards-compliant JWT library.
HS256 vs RS256 vs ES256 — which should I use?
HS256 (HMAC-SHA256): symmetric, one shared secret. Fast and simple but verifier can also sign. Use for internal services where you control both endpoints (an API and its own clients). RS256 (RSA + SHA-256): asymmetric, private key signs, public key verifies. Use for OAuth / OpenID Connect where many independent verifiers fetch the public key from a JWKS endpoint. Signatures are large (~256 bytes for RSA-2048). ES256 (ECDSA P-256 + SHA-256): asymmetric, smaller signatures (~64 bytes), faster than RS256. EdDSA (Ed25519): newest, fastest, simplest — the modern default for greenfield asymmetric JWT. Need the keys? Use the Key Pair Generator at /tools/key-pair-generator/.
How long should a JWT live?
Depends on the token's role. Access tokens: 5-60 minutes — short enough that a leaked token doesn't grant prolonged access, long enough to avoid constantly hitting the auth server. Refresh tokens: hours to weeks, stored more securely (httpOnly cookie or secure server-side) and used only to obtain new access tokens. ID tokens (OpenID Connect): 5-30 minutes — they prove identity at the moment of authentication, no need for long lifetime. Session tokens (custom): 24 hours to 7 days, depending on the app's session model. Don't make tokens longer than necessary — JWT's stateless design has no built-in revocation, so a long-lived leaked token stays valid until exp.
Where should I store the signing key?
Never in source code, never in git, never in browser storage. Production options, best to worst: (1) dedicated secrets manager (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager) with IAM-controlled access; (2) HSM or cloud KMS (AWS KMS, GCP Cloud KMS, Azure Key Vault) where the private key never leaves the hardware; (3) environment variables injected by orchestrator (Kubernetes secrets mounted as env, Docker Swarm secrets) with role-based access; (4) encrypted file on disk with restrictive permissions (chmod 600, owned by service account only). For HS256, the secret is a single random string ≥32 bytes. For RS256/ES256/EdDSA, the private key (PEM or JWK) is what you protect; the public key is freely distributed.
Is signing JWTs in the browser safe?
For learning and debugging, yes — this tool runs entirely in your browser, with no network requests and no logging. Your secret and the resulting JWT never leave your device. However, for production: never sign JWTs client-side. The signing key would have to be exposed to the client, which defeats the purpose — anyone who has the key can forge any token they want. The correct pattern is: server holds the signing key, client authenticates somehow (credentials, OAuth flow), server issues the signed JWT, client carries the JWT for subsequent requests. This tool is appropriate for testing JWT verifiers, generating sample tokens, and learning the format — not for production token issuance.
What claims should I include in a JWT?
Required for almost every JWT: iat (issued at, Unix timestamp), exp (expiration, Unix timestamp). Recommended: sub (subject — the user or entity the token represents), iss (issuer — who created the token), aud (audience — who the token is for). Conditional: nbf (not before — if the token shouldn't be valid until a future time), jti (unique JWT ID, useful for revocation tracking). Custom claims: role, permissions, tenant, email — anything your application needs. Critical: claims are not encrypted, just base64-encoded. Don't put secrets, passwords, or sensitive PII in JWT claims — they're readable by anyone with the token (use the JWT Decoder to inspect).
Why is my JWT signature different from another tool's output?
Two common causes. First, JSON canonicalization: { 'sub':'1234' } and {'sub': '1234'} produce different base64 encodings even though they represent the same object. Most JWT libraries serialize with no whitespace; check the exact JSON formatting. Second, secret encoding for HS*: some libraries treat the secret as a UTF-8 string and HMAC the bytes directly, others base64-decode the secret first. If the secret is non-ASCII or looks like base64, this matters. Third (for RS*/ES*), check the key format — PKCS#8 vs PKCS#1 vs encrypted PEM all parse differently. When in doubt, sign the exact same header+payload with both tools and compare to find the discrepancy.
Can I include the public key in the JWT itself?
Yes — the JWT header supports a jwk field (JSON Web Key) that embeds the verifier's public key directly in the token. This is convenient for ad-hoc token verification but rarely used in production: the standard pattern is for verifiers to fetch keys from a known JWKS endpoint (https://your-auth.example.com/.well-known/jwks.json) rather than trust keys embedded in the token. The reason: a verifier that trusts the jwk field accepts whatever key the token says to use, which is a critical security flaw — an attacker can substitute their own key pair, sign a forged token, and embed their public key in the jwk header. Always verify against keys you fetched, not keys embedded in the token.
Share This Tool
Found this tool helpful? Share it with others who might benefit from it!
💡 Help others discover useful tools! Sharing helps us keep these tools free and accessible to everyone.