JWT Generator

THE PRACTICAL GUIDE · NORMANDIN SYSTEMS

Get more from JWT Generator

JWT Generator: JWT Token generator and editor. A JWT packages claims with a header and a cryptographic protection choice, while the receiving application decides which algorithms, issuers, and audiences it accepts. Cryptographic operations depend on exact agreement about algorithms, keys, encodings, and message formats. A successful local demonstration is useful for understanding a workflow, but interoperability should be checked with the program or protocol that will consume the output. Keep secret material separate from public information and use disposable test keys while experimenting. Encryption, signing, and hashing answer different questions: confidentiality, authenticity, and data representation are not the same property. Record the relevant parameters and verify the reverse operation or verification result before relying on an output.

Guide updated October 13, 2026

How to use this tool

1. Begin with a representative input. For a practical test, use: Demonstration claims, a selected algorithm, and disposable signing material. Replace demonstration values only after you understand the output.
2. Use sample plaintext and disposable keys to select the operation and supply the key material or parameters requested by the interface.
3. Inspect the result and any error message, checking algorithm choices, key formats, and whether the operation expects public or private material.
4. Test decryption or verification with the intended receiving application and retain the parameters needed to reproduce that workflow.

SEE IT IN PRACTICE

A worked example

Algorithm: HS256
Secret encoding: Raw text
Secret: example-secret
Payload: {"sub": "demo-user", "iss": "https://issuer.example", "aud": "demo-api", "exp": 1893456000}

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJkZW1vLXVzZXIiLCJpc3MiOiJodHRwczovL2lzc3Vlci5leGFtcGxlIiwiYXVkIjoiZGVtby1hcGkiLCJleHAiOjE4OTM0NTYwMDB9.AbvaG4dfvC6dkALggm9AyfxEi2TuBhwduiCKEfDJLqg

The current signing implementation protects the header {"alg":"HS256"} and serializes the supplied claims. The example secret is public demonstration material and must never protect a real token. The visible header summary can include typ even though this generated protected header omits it.

Read claims in their application context

The sub claim identifies a subject within the issuer’s context. The iss claim identifies the issuer, and aud identifies the intended audience. NumericDate claims such as exp, nbf, and iat use seconds relative to the Unix epoch, not milliseconds. An application must decide which claims are required and how they affect access. A claim being present does not make its value trustworthy.

Separate token shape from token acceptance

A common signed JWT has three Base64url segments separated by periods: header, payload, and signature. The first two segments are readable representations, not encryption. The verifier should use its configured algorithm policy and trusted key rather than blindly accepting the header’s alg value. A well-formed token can still be expired, intended for another audience, or signed by an untrusted key.

When this tool is useful

• Create an authentication test token
• Inspect claim serialization
• Check verifier integration

Tips for a better result

• A token’s existence does not grant authority unless the receiver validates it under an appropriate trust policy.
• Public keys may be distributed, while private keys and shared secrets require controlled storage and handling.
• An output that looks like encoded text is not enough to prove compatibility; test it with the actual receiving implementation.

Frequently asked questions