SECURITY: This tool runs entirely in your browser — your secret never leaves your device. However, paste TEST secrets only. Real production secrets should never be entered into any web page, even a local one.
✓ Valid JSON✗ Invalid JSON
How to Use JWT Encoder
Build a JSON Web Token (JWT) from scratch: enter your payload as JSON, provide a secret key, choose the HMAC algorithm (HS256, HS384, or HS512), and press Generate. The tool Base64URL-encodes the header and payload, signs them with the WebCrypto API using your secret, and outputs the complete three-part JWT. Copy the token with one click. Everything — including the signing — happens locally in your browser; your secret key is never transmitted.
About JWT Encoder
A JSON Web Token (JWT, pronounced "jot") is a compact, URL-safe way of representing claims between two parties — typically an authentication server and an application. When you log into a website or an API, a JWT is often what gets created on the server and sent back to your browser, and every subsequent request you make to that service carries the JWT (usually in an Authorization header) to prove who you are without the server needing to maintain a session record for you. A JWT consists of three Base64URL-encoded parts separated by dots: header.payload.signature. The header describes which algorithm was used to sign it (for example, {"alg":"HS256","typ":"JWT"}). The payload contains the claims — the actual data you want to transmit, such as a user ID, an expiration time, or any custom fields your application uses. The signature is a cryptographic hash of the header and payload, created with the algorithm and a secret key that only the signing server knows, which lets anyone who knows the secret verify that the token has not been tampered with since it was created.\n\nAn important distinction exists between encoding and signing a JWT (what this tool does) and decoding and verifying one (what a separate JWT Decoder tool does). Encoding means constructing the token — creating the header, serializing the payload as JSON, Base64URL-encoding both parts, signing them, and assembling the final three-part string. A decoder reads an existing token — it splits the three parts, decodes the header and payload to show you what is inside, but it cannot verify the signature because verification requires the secret key, which only your server has (or should have — never paste a real production secret into any online tool).\n\nThis encoder comes with a critical security warning: NEVER paste a real production secret key into this or any online tool. Even though this tool runs entirely in your browser and never transmits data, secrets entered into a web page can be read by browser extensions, developer tools, or malware on the local machine. This tool is designed for development, testing, and learning — generate JWTs with test secrets to understand the format, debug payload structure, or prototype authentication flows.
Details & Tips
JWT structure in detail, using HS256 with secret key and a sample payload as an example:\n\nHeader (before Base64URL encoding): {"alg":"HS256","typ":"JWT"}. This is JSON with two keys: alg (the signing algorithm, one of HS256, HS384, or HS512) and typ (always "JWT" for a JWT). After Base64URL encoding, it becomes a compact alphanumeric string that is safe to include in a URL, an HTTP header, or a cookie.\n\nPayload (before Base64URL encoding): whatever JSON you typed. Common standard claim names include sub (subject — who the token is about, often a user ID), iat (issued-at timestamp in seconds since Unix epoch), exp (expiration timestamp in seconds), iss (issuer — who created the token), aud (audience — who the token is intended for), and nbf (not-before timestamp). You can include any custom claims alongside the standard ones. After Base64URL encoding, the payload is another compact string.\n\nSignature: created by taking the header and payload (after Base64URL encoding), concatenating them with a dot (.), and computing an HMAC using the chosen hash algorithm with the secret key. The resulting HMAC bytes are then Base64URL-encoded. The signature ensures integrity — if anyone modifies the header or payload, the signature will not match, and the token will be rejected by any properly implemented verifier.\n\nThe complete JWT is: encodedHeader.encodedPayload.encodedSignature — three Base64URL strings joined by dots, typically around 150-300 characters long depending on payload size and algorithm choice.\n\nBase64URL encoding differs from standard Base64: it uses - instead of + and _ instead of /, and it strips the = padding characters. This makes it safe to include in URLs and HTTP headers without additional percent-encoding. The tool uses the WebCrypto API's crypto.subtle.importKey (to import the secret as an HMAC key), crypto.subtle.sign (to compute the HMAC), and a custom Base64URL encoder (to format the output correctly for JWTs).
Frequently Asked Questions
Is it safe to paste my real secret key here?
No. Even though this tool runs entirely in your browser and never transmits data, secrets entered into a web page can be read by browser extensions, developer tools, or malware. Only use test secrets for development and learning.
What is the difference between this JWT Encoder and a JWT Decoder tool?
The encoder creates (signs) new tokens — you provide a payload and secret, and it produces the complete three-part JWT. A decoder reads existing tokens — it shows you the header and payload inside an existing JWT but cannot verify the signature without the secret.
Which algorithm should I choose?
HS256 is the most common choice and produces the shortest signature (good for keeping tokens compact in HTTP headers). HS384 and HS512 use stronger hash functions and produce longer signatures. All three are HMAC-based and require the same secret to sign and verify.
What should my payload contain?
Any valid JSON. Common fields include sub (subject or user ID), iat (issued-at timestamp), exp (expiration timestamp), and your own custom fields. The payload is not encrypted — anyone can decode it by splitting the JWT on dots and Base64URL-decoding the middle part.
Why does the tool say my payload is not valid JSON?
The payload must be strictly valid JSON — check for trailing commas, unquoted keys, or single quotes instead of double quotes. Use a JSON Formatter tool to validate and prettify your payload before pasting.
What is Base64URL encoding and how is it different from Base64?
Base64URL uses - instead of + and _ instead of /, and drops the = padding. This makes it safe for use in URLs and HTTP headers without additional percent-encoding. JWTs always use Base64URL, never standard Base64.
Can I generate RS256 or ES256 tokens with this tool?
No. This tool supports the HMAC-based algorithms only (HS256, HS384, HS512), which use a shared secret. RS256 (RSA) and ES256 (ECDSA) require a public/private key pair and are more complex to generate in a browser — WebCrypto supports them, but this tool does not yet expose them.
Is my secret key sent to a server?
No. The signing is performed by the WebCrypto API (crypto.subtle.sign) entirely within your browser. The secret key is never transmitted, logged, or stored — it stays on your device. That said, paste test secrets only (see first FAQ).
What makes a JWT signature secure?
The signature depends on the entire header and payload, plus the secret key. If any part of the header or payload is modified after signing, the signature will no longer match, and the token will be rejected by a verifier. The security lies entirely in keeping the secret key secret.
Can I set an expiration time in my JWT?
Yes — include an exp claim set to a Unix timestamp (seconds since 1970-01-01). The verifier should reject tokens where the current time is past the exp value. This tool does not enforce or validate timestamps; it only assembles whatever JSON you provide.