JWT Encoder

How the JWT Encoder works

A JSON Web Token is three Base64url strings joined by dots: a header, a payload and a signature. The header names the algorithm, the payload carries the claims, and the signature proves that whoever made the token knew the secret. Anyone can read the first two parts. Only someone holding the key can produce a signature that verifies, which is what makes a JWT tamper-evident rather than secret.

How the JWT encoder builds a token

The tool writes a header of {"alg": "HS256", "typ": "JWT"}, adding kid if you fill in a key ID. It encodes the header and your payload as UTF-8 JSON, converts each to Base64url (the URL-safe alphabet with - and _ and no = padding) and joins them with a dot. That string is the signing input. It then runs HMAC with SHA-256, SHA-384 or SHA-512 over the signing input using your secret, encodes the result the same way and appends it as the third part.

Because the payload is serialised exactly as typed, property order and spacing do not matter to a verifier. What matters is that the verifier checks the signature against the same bytes. That is why you should never re-encode a token's payload after signing it.

Choosing HS256, HS384 or HS512

All three are HMAC algorithms from RFC 7518, which means the same secret both signs and verifies. HS256 is by far the most common and is what most libraries assume by default. HS384 and HS512 use longer hashes, giving longer signatures without a meaningful practical security gain for most uses. Pick whatever the receiving service expects. A mismatch between the alg in the header and the algorithm the server is configured for is the most common cause of "invalid signature" errors.

If the service publishes a JWKS endpoint or asks for RS256 or ES256, it uses public-key signatures. Those need a private key rather than a shared secret and are not what this tool makes.

How long the secret should be

RFC 7518 says an HMAC key must be at least as long as the hash output: 32 bytes for HS256, 48 for HS384 and 64 for HS512. The Secret strength reading checks this and tells you when the key is short. A short secret still produces a valid token, but it can be brute-forced offline by anyone who captures one token, because the header and payload give them everything they need to test guesses. Dictionary words and short passphrases fall in seconds on a single graphics card.

Generate secrets with a random source rather than inventing them. Many frameworks store the secret as Base64 or hex, so the Secret encoding option lets you paste it in that form. Choose Text (UTF-8) only when the server really uses the literal characters as the key.

Expiry and the standard claims

Setting an expiry adds two registered claims from RFC 7519. iat (issued at) is the current time and exp is the time the token stops being valid, both in seconds since 1 January 1970 UTC. The Expires reading shows that moment as a readable date. Any iat or exp you typed in the payload is overwritten when you choose an expiry; pick No expiry to keep your own values.

Other registered claims are worth including when the receiving service checks them:

• sub: the subject, usually a user ID.
• iss: the issuer, a string naming who made the token.
• aud: the audience, the service the token is meant for.
• nbf: not before, a time before which the token must be rejected.
• jti: a unique token ID, used to block replay.

Servers usually allow a minute or two of clock skew when checking exp and nbf, so a token made on a machine with a wrong clock may be rejected early or accepted late.

What not to put in a JWT

The payload is encoded, not encrypted. Anyone who sees the token can decode it in one step, so never include passwords, card numbers, personal data you would not show the user, or internal secrets. Keep tokens small, too: they travel with every request, and many proxies cap request headers at around 8 KB.

Using the result safely

Treat the output as a credential. A signed token with a long expiry works for whoever holds it, and an HMAC token cannot be revoked without changing the secret or keeping a deny list. Use short lifetimes for anything that grants real access, and prefer test secrets when experimenting. To check what a token contains, paste it into a decoder; to confirm the signature, use a verifier with the same secret. Both steps catch the encoding and algorithm mismatches that cause most failed logins during integration work.

Related tools