UseToolSuite UseToolSuite

JWT Token Builder

Build and sign JWT tokens with custom claims, expiration, and HMAC (HS256/384/512). Set registered claims and a custom payload — signed in-browser.

Never sent to any server

Anatomy of a JWT

A JWT is three Base64URL strings joined by dots: header.payload.signature.

PartContainsEncrypted?
HeaderAlgorithm + token typeNo — readable
PayloadClaims (the data)No — readable
SignatureHMAC/asymmetric over header+payloadn/a (it’s the proof)

The signature is what makes a JWT trustworthy: change a single character of the header or payload and the signature no longer validates. But — worth repeating because it’s the most common mistake — the payload is merely encoded, not hidden. Paste any JWT into a decoder and its claims are plainly visible.

Set the registered claims deliberately

JWTs define standard claims with specific meanings (RFC 7519). The time-based ones are the difference between a safe token and a liability:

  • exp (expiration) — always set it. A token with no expiry is valid forever, so a single leak is permanent. Short-lived access tokens (minutes to an hour) limit the blast radius.
  • nbf (not before) — optional; rejects a token used before a start time.
  • iat (issued at) — lets you reason about token age and revoke everything issued before a cutoff.
  • iss / aud — bind the token to a specific issuer and intended audience so a token minted for one service can’t be replayed against another.

Where to store tokens matters as much as how you sign them

A correctly signed token is still dangerous if it’s stored carelessly. Putting JWTs in localStorage exposes them to any XSS on the page — a single injected script reads every token. An httpOnly cookie keeps the token out of JavaScript’s reach (mitigating XSS theft) at the cost of needing CSRF protection. The common production pattern is a short-lived access token plus a longer-lived refresh token, with the refresh token kept in an httpOnly, Secure, SameSite cookie. Signing is only half the security story; storage is the other half.

Build for testing, sign for real elsewhere

This builder signs with HMAC algorithms (HS256/384/512) using the Web Crypto API entirely in your browser — your secret never leaves the page — which makes it ideal for creating test tokens and learning the structure. But don’t generate production tokens with your real secret in any browser tool: issue those server-side with proper key management, rotation, and an algorithm allowlist. To inspect tokens you receive (and confirm exactly what claims they carry), pair this with the JWT Decoder.

JWT Token Builder Powered by UseToolSuite — free browser tools
is compiled away. */}

Last updated

How helpful was this tool?

Click to rate

Embed this tool on your site

Paste this snippet into any HTML page or blog post to embed a live, fully working copy of JWT Token Builder. Free for any use.

Key Concepts

HMAC

Hash-based Message Authentication Code — a mechanism for verifying both data integrity and authentication using a cryptographic hash function and a secret key. In JWTs, HMAC algorithms (HS256/384/512) create a signature by hashing the header and payload with the secret key. Both the token creator and validator must share the same secret.

Claims

Key-value pairs in the JWT payload that make assertions about the subject. Registered claims (iss, sub, exp) have predefined meanings in RFC 7519. Public claims should use collision-resistant names. Private claims are custom fields agreed upon between the token creator and consumer.

Frequently Asked Questions

What algorithms does this tool support?

The JWT Builder supports HMAC-based algorithms: HS256 (HMAC with SHA-256), HS384 (HMAC with SHA-384), HS512 (HMAC with SHA-512), and "none" (unsigned). All HMAC signing is performed using the Web Crypto API for cryptographic correctness. RSA and ECDSA algorithms require public/private key pairs and are not supported in this browser-based tool.

What are registered claims?

JWT registered claims are standardized fields defined in RFC 7519: iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not before), iat (issued at), and jti (JWT ID). They have specific meanings that JWT libraries and validators understand. All registered claims are optional but recommended for security.

Can I use these tokens in production?

While the tokens generated by this tool are cryptographically valid, you should not use any online tool to generate production tokens with your real secret keys. This tool is designed for development, testing, and learning. Generate production tokens server-side with proper key management, rotation, and environment isolation.

What is the "none" algorithm?

The "none" algorithm creates an unsigned JWT (also called an "unsecured JWT"). The token has no signature, so anyone can read and modify the payload. This is only useful for development and testing — never accept "none" algorithm tokens in production, as it is a common JWT security vulnerability.

How is this different from the JWT Decoder?

The JWT Decoder takes an existing token and splits it into readable header and payload. The JWT Builder goes in the opposite direction: you define the claims and algorithm, and the tool creates a signed token. Use the Builder to create test tokens and the Decoder to inspect tokens you receive from APIs.

Is the JWT payload encrypted — is it safe to put sensitive data in it?

No. A standard signed JWT (JWS) is Base64URL-encoded, not encrypted — anyone holding the token can decode and read the payload with no key at all. The signature only prevents TAMPERING; it does nothing to hide the contents. So never put passwords, secrets, or sensitive personal data in JWT claims. Treat the payload as public, readable text. If you genuinely need confidential claims, that's a different construct (JWE, JSON Web Encryption), not the signed tokens this builder creates. For normal auth, keep claims to non-sensitive identifiers (user id, roles, expiry) and look the rest up server-side.

What is the alg=none / algorithm-confusion attack, and how do I avoid it?

Two classic JWT vulnerabilities target the header's 'alg' field. The 'none' attack: an attacker changes alg to 'none', strips the signature, and a naive verifier that trusts the header accepts the unsigned token — instant forgery. The algorithm-confusion attack: a server expecting RS256 (asymmetric) is tricked into verifying an HS256 token using the PUBLIC key as the HMAC secret, which the attacker knows, letting them forge tokens. Defense for both: never let the token dictate the algorithm. Configure your verifier with an explicit allowlist of accepted algorithms, reject 'none' outright, and bind verification to the expected key type. The token header is attacker-controlled — your server decides the algorithm, not the JWT.

Troubleshooting & Technical Tips

Generated token fails validation on the server

Ensure the secret key matches exactly between this tool and your server — trailing spaces, newlines, or encoding differences (UTF-8 vs Base64) are the most common causes. Also verify the algorithm matches: if your server expects HS256, generate with HS256. Check that the "exp" claim has not already expired.

Custom claims JSON parse error

Custom claims must be valid JSON. Common mistakes: using single quotes instead of double quotes, trailing commas, or unquoted keys. Correct format: {"role": "admin", "permissions": ["read", "write"]}.

Related Guides

JWT Security: What's Safe to Decode, and What You Should Never Paste Online

A JWT is just Base64 — anyone can read it. How to inspect tokens safely, why pasting a live token into a random site is risky, and how signatures protect you.

API Authentication Methods Compared: API Keys, OAuth 2.0, JWT, HMAC & mTLS

API authentication compared: API keys, Basic auth, Bearer tokens, OAuth 2.0, JWT, HMAC request signing, and mutual TLS — and when to use each.

Related Tools

JWT Decoder

Encoding & Decoding Tools

Base64 Encoder / Decoder

Encoding & Decoding Tools

Hash Generator

Encoding & Decoding Tools

HMAC Generator

Encoding & Decoding Tools