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.

Last updated

JWT Token Builder encodes and decodes locally, so nothing you paste is ever transmitted. It's one of the free Encoding & Decoding Tools on UseToolSuite. Use it below, then scroll down for a step-by-step guide, answers to common questions, and related tools.

Never sent to any server

What is the JWT Builder & Decoder?

The JWT Builder & Decoder is a critical security tool for developers working with JSON Web Tokens, designed with a strict zero-data-transmission policy. When debugging authentication flows, pasting real user tokens or private keys into online tools poses a massive security risk. This utility performs all decoding, encoding, and signature verification entirely locally in your browser. Whether you are inspecting the payload of a stale session token or manually signing a new JWT with a secret key for API testing, this tool ensures your credentials never leave your machine.

How does it work?

All cryptographic operations are executed using the Web Crypto API or local JavaScript libraries (like `jose` or `crypto-js`). When decoding, it simply base64url-decodes the header and payload segments. When signing or verifying, it uses the provided secret or key to run the HMAC SHA-256 (or RSA) algorithm locally, generating the signature hash and comparing it against the token.

Common use cases

1. Safely inspecting the payload claims of a production JWT to debug user role or expiration issues.
2. Manually generating and signing custom JWTs with specific claims for testing backend authentication middleware.
3. Verifying if a token signature is valid against a known secret during local API development.

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.

How helpful was this tool?

Click to rate

Key Concepts

Essential terms and definitions related to JWT Token Builder.

JWT (JSON Web Token)

A compact, URL-safe token format (RFC 7519) for securely transmitting claims between parties. A JWT consists of three Base64URL-encoded parts separated by dots: header.payload.signature. The header specifies the algorithm, the payload contains claims, and the signature verifies integrity.

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.

Is my secret key sent to a server?

No. All JWT generation and HMAC signing happens entirely in your browser using the Web Crypto API (crypto.subtle). Your secret key never leaves your device. The tool makes no network requests during token generation.

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

Common errors developers encounter and how to resolve them.

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

In-depth articles covering the concepts behind JWT Token Builder.

Related Tools