JWT Generator
Generate an unsigned JWT from header and payload JSON for development and testing. Never use tokens generated here for production authentication.
Calculator
This generates UNSIGNED tokens only
Every token produced here has an empty signature segment — nothing is cryptographically signed. This tool does not implement JWS/JWE and never will; it exists purely so you can construct a header/payload pair for development, testing, and learning how JWTs are structured. Tokens generated here must never be used for production authentication — anyone can read, modify, or forge an unsigned token, and no real system should ever accept one as proof of identity.
Generated JWT
—Decoded Header
—Decoded Payload
—Header Size
— B
Payload Size
— B
Token Length
— chars
Result
—
How JWT Generator Works
This tool generates UNSIGNED tokens only
Every token this tool produces has an empty signature segment — nothing is cryptographically signed. It does not implement JWS (JSON Web Signature) or JWE (JSON Web Encryption), and it never will. It exists purely to let you construct a header/payload pair and see the resulting token structure, for development, testing, and learning. A token generated here must never be used for production authentication. Anyone can read, modify, or forge an unsigned token — there is nothing here for a real system to verify.
What is a JWT?
A JSON Web Token (JWT) is a compact, URL-safe way to represent a set of claims — statements about a user or entity — as a signed token that can be passed between parties. JWTs are the standard mechanism behind most modern API authentication: a client presents a JWT with each request, and the server verifies its signature to trust the claims inside without needing a database lookup on every call.
JWT Structure
A JWT is three Base64URL-encoded segments joined by dots: header.payload.signature.
Each segment decodes to its own piece of the token:
| Segment | Contains |
|---|---|
| Header | Metadata — which algorithm was used to sign the token, and its type |
| Payload | The actual claims — arbitrary JSON data about the subject |
| Signature | A cryptographic signature over the header and payload, proving they weren't altered and were issued by whoever holds the signing key |
Header
The header is a small JSON object, almost always containing alg (the signing
algorithm, e.g. HS256 or RS256) and typ (conventionally "JWT"). This tool defaults to
{"alg":"none","typ":"JWT"} — see below for why.
Payload
The payload holds the claims — arbitrary key-value data, plus a handful of standard registered
claim names defined by RFC 7519: sub (subject), iss (issuer),
aud (audience), exp (expiration, as a Unix timestamp),
nbf (not valid before), iat (issued at), and jti (a unique
token ID). None of these are required — a payload can contain any JSON object.
Why "alg":"none" Exists
The JWT specification itself defines "alg":"none" as a legitimate value, meaning "this
token is explicitly unsigned — do not attempt to verify a signature." It has real, narrow uses (like
passing already-trusted, internally-generated claims between services within a single trust boundary
where signing would be redundant overhead), but it's also the source of one of the most infamous JWT
vulnerabilities: some early libraries would accept ANY token with alg: none as valid,
letting an attacker strip the signature off a legitimate token, set the algorithm to none, and have it
accepted as authentic. Modern libraries reject none by default unless explicitly opted
into — a JWT generator that defaults to it, as this tool does, is a deliberate, honest way to
illustrate exactly what an unsigned token looks like without pretending it's something it's not.
Why Unsigned JWTs Are Dangerous in Production
A signature is the ONLY thing that makes a JWT trustworthy — it's what proves the claims inside
haven't been tampered with and genuinely came from whoever holds the signing key. An unsigned token, or
one whose signature isn't actually checked, can be freely edited by anyone: change "role":
"user" to "role": "admin", and an unsigned token will happily "say" whatever the
holder wants. Never accept a token as proof of anything without verifying its signature against the
issuer's actual key.
JWT vs JWS
Precisely speaking, a "JWT" is a claims format; a "JWS" (JSON Web Signature) is the general mechanism for signing arbitrary content, of which a signed JWT is one specific application. In casual usage "JWT" almost always implies a signed (JWS-wrapped) token — this tool deliberately produces the unsigned, illustrative case instead, and says so clearly, rather than implementing real JWS signing (which would require managing real cryptographic keys, well outside this tool's educational scope).
Common Mistakes
- Using a tool-generated token in a real application, "just to test." If any code path treats it as authenticated, that path has effectively no authentication at all.
- Assuming JWTs are encrypted. They're not — the header and payload are only Base64URL-encoded, not encrypted, and anyone can decode and read them (this platform's own JWT Decoder does exactly that). Don't put secrets in a JWT payload.
- Forgetting that a signature proves origin, not confidentiality. Even a correctly signed JWT is fully readable by anyone who has it — signing prevents tampering, it doesn't hide the contents.
Related Tools
Working with JWTs often overlaps with other developer utility tasks: decode and inspect an existing token's claims and expiry with the JWT Decoder, understand the Base64URL encoding underneath with the Base64 Encoder, validate or reformat the header/ payload JSON with the JSON Formatter or JSON Validator, or fingerprint a token string with the Hash Generator.
Accuracy & Sources
Last reviewed: August 2026. Formula source: RFC 7519 — JSON Web Token (JWT). All calculations run in your browser. No data is sent to any server.
Frequently Asked Questions
No — never. Every token this tool produces is unsigned (an empty signature segment). Anyone can read or modify it freely, and no real authentication system should ever accept it as proof of identity. This tool exists strictly for development, testing, and learning how JWT structure works.
"none" is a value the JWT specification itself defines, meaning "this token is explicitly unsigned." Defaulting to it is the most honest way to show exactly what an unsigned token looks like, rather than implying a fake algorithm actually signed something. You can still change the header to any alg value you like — this tool never signs regardless of what the header claims.
No — it never signs anything, regardless of the header you provide. The generated token's signature segment is always empty. If you need a genuinely signed token for testing, you'll need a library or service that performs real cryptographic signing with an actual secret or private key.
No — by default, a JWT's header and payload are only Base64URL-encoded, not encrypted. Anyone who has the token can decode and read its contents (this platform's JWT Decoder does exactly that). Never put secrets or sensitive data directly in a JWT payload.
Yes — the generated token follows the standard JWT structure (Base64URL-encoded header and payload, joined by dots, with an empty signature segment), so any standard JWT decoder can read the header and payload. It just won't have a valid signature to verify, because there isn't one.
Any valid JSON object — there's no strict requirement beyond that. Conventionally the header includes alg and typ, and the payload includes some combination of the registered claims (sub, iss, aud, exp, nbf, iat, jti) plus whatever custom fields you need, but this tool accepts any JSON object for either field.