JWT encoder

How a JWT is built

A JSON Web Token has three parts separated by dots: a header saying which algorithm signed it, a payload of claims (user ID, roles, expiry), and a signature. The header and payload are just JSON encoded in Base64url, so anyone can read them; the signature proves the token was issued by someone who knows the secret and has not been changed since.

With HS256 the signature is an HMAC-SHA256 of header.payload using a shared secret, the same secret the API uses to verify. That makes HS256 tokens handy for development, tests and services that share a key.

Worked example

The well-known example payload {"sub":"1234567890","name":"John Doe","iat":1516239022} signed with the secret your-256-bit-secret gives a token ending in SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c, the same token shown in countless tutorials. Change one character of the payload and the signature changes completely.

Expiry

Turn on issued at and set expires in to add iat and exp claims, as most APIs require. Use the JWT decoder to inspect the result.

The page parses your payload as JSON, adds iat and exp if requested, and builds the header {"alg": "HS256", "typ": "JWT"} (or HS384/HS512). Both are serialised, encoded as UTF-8 and written in Base64url without padding, then joined with a dot. The browser's Web Crypto API computes the HMAC of that string with your secret, as RFC 7518 specifies, and the signature is appended in Base64url. The table shows the header and warns when the secret is shorter than the hash size. The secret never leaves this tab and is not stored.