JWT Builder

Two things decide whether a token you build here will actually be accepted, and both of them are usually left silent.

The first is how the secret is read. Most services publish an HMAC secret in base64, and their server decodes it to bytes before signing. A builder that always reads the secret as text signs against completely different bytes, so the token is well formed, verifies against itself, and is rejected by the service, and the failure looks exactly like a wrong secret. The encoding is therefore a setting here (text, base64, base64url or hex), the panel states how many bytes the key turned out to be and which reading produced them, and the tests check that a base64 secret read as base64 gives a token node:crypto verifies against the decoded bytes while the same secret read as text does not.

The second is key length. RFC 7518 section 3.2 says a key at least as large as the hash output MUST be used, so 256 bits for HS256, 384 for HS384 and 512 for HS512. A shorter key still produces a signature that verifies perfectly well, which is exactly why nobody notices; the tool signs anyway and says so, with the numbers. There is a generator that produces a secret of the right length.

The algorithm in the header is not a field you can edit: it is written from the algorithm the signature was actually made with, so the two can never disagree. That matters because a token whose header claims one algorithm and whose signature is another is what a confused verifier trips over, and it is the shape of the algorithm confusion attack the decoder refuses. A key id can be set and goes into the header, which is how a server holding a JWKS picks which key to check against.

The payload is edited as JSON and checked against RFC 7519 section 4.1 as you type, without ever refusing to build: exp, nbf and iat have to be numbers of seconds rather than strings or milliseconds; iss, sub and jti have to be strings; aud has to be a string or an array of strings; and the tool points out an exp that has already passed, an nbf in the future, an exp that is not after iat, and a payload with no exp at all. Minting an already-expired token on purpose is a legitimate thing to want, so those are notes rather than refusals.

Every token is signed with the platform’s Web Crypto and then decoded and verified again with the same verifier the decoder tool uses, and the panel reports the result while being clear about what that proves: it is the tool checking itself, not evidence your server will agree. The tests go further and verify every token with node:crypto, a different implementation, in both directions.

Signing is asynchronous and several runs can be in flight while you type. Each run carries a sequence number and only the latest may write its result, so the token on screen always belongs to the payload in the box rather than to whichever run happened to finish last. Thirty rapid payload changes in the browser tests end with the token matching the thirtieth.