JWT Generator

Where a signed token is needed right now

Testing authorization is the first scene. A frontend developer checks what happens when exp expires: set exp a minute ahead, wait, and see whether the re-login screen appears. A backend developer receives a token from the frontend and wants to make sure the middleware correctly rejects a tampered signature: generate a valid token, change one letter, and both cases are laid out. QA prepares a fixture set: a valid token, an expired one, a token without a role, a token with someone else's sub — all of it takes minutes.

The second scene is learning and teardown. On a real example you can see how the payload becomes a string, how the signature reacts to a single changed character, and why a server will not accept a token with an edited claim. A student or junior who has assembled a token by hand no longer confuses signing with encryption and understands why a password never goes into the payload. The full format walkthrough lives in the article JWT: what is inside a token — it complements the hands-on practice here well.

• Fixtures for automated tests: valid, expired and tampered tokens
• Checking exp handling on the frontend and middleware on the backend
• Debugging role and sub in authorization without running an auth server
• Study assignments on the JWT format and HMAC signatures
• Demos and documentation: show the team a real token, not a mock

Typical mistakes when generating tokens

The first mistake is using a real production secret in the browser form. Even if the page sends nothing over the network, the secret stays in browser input history and in extension memory, and the habit of typing it into third-party forms is dangerous in itself. A generator deserves a test secret such as a string of twelve random characters; real keys stay on the server and never touch the form.

The second mistake is mixing up seconds and milliseconds in iat and exp. The standard demands seconds; pass milliseconds and the number lands far in the future, so a token with a formally correct exp lives for centuries. The third is forgetting the payload is readable by everyone: passwords, card numbers and personal data do not go there, signed or not. And the fourth is believing an HS256 signature protects the content from reading: it protects only against modification.

• Real secrets never go into browser generators, only test ones
• iat and exp are Unix seconds, no milliseconds
• The payload is not encrypted: no secret data belongs there
• The signature guarantees immutability, not secrecy of content
• An overly long exp makes access revocation impossible
• Changing the payload by one symbol changes the entire signature

Worked example: a token in three parts

Take a minimal payload: sub set to user-1, name set to Ivan, iat and exp filled by the buttons. The HS256 header is fixed, so its base64url form is always the same. The payload after packing comes to roughly a hundred characters — Cyrillic in JSON becomes UTF-8, so Ivan takes more bytes than Latin text. The signature is computed over the header.payload string with your secret and turns into 43 base64url characters. The parts joined by dots make up the finished token, a couple hundred characters long, easy to copy in one go.

Next it helps to look at the token through a decoder: it shows the same claims and the signature separately. Change one letter in the payload and re-sign — the signature changes entirely, because HMAC spreads the change across all 32 bytes. Change a letter and do not re-sign — the server rejects the token at signature verification. The table below shows what goes where.

None of the three parts contains the secret: the secret is needed only at signing and at verification and never enters the token itself.

What to read and what pairs with the generator

The generator and the decoder make a pair: one assembles a token, the other takes it apart. Once the token is ready, open the JWT decoder and check the claims. To see the math behind the signature, open the HMAC generator — it shows how a message and a key become 32 signature bytes, with test vectors to check against. Real secrets are made as random strings: the password generator suits that, and the length and entropy requirements are covered in the article on a strong password.

For a deeper dive the standards remain the source: RFC 7519 describes JWT, and RFC 7515 describes the JWS signing scheme used here. On this site the format is taken apart piece by piece in the article JWT: what is inside a token, and the base64url packing in the guide to Base64. Together these four texts cover practice and theory: assemble, parse, understand the signature, understand the packing.

• Generator and decoder complement each other: build, then verify
• The HMAC generator shows signature math on verifiable vectors
• Real secrets are generated as random strings and kept on the server
• RFC 7519 defines the claims, RFC 7515 defines the signature
• For several services with separate keys, look toward RS256