JWT Builder

Output is a JWS Compact Serialization per RFC 7515: base64url(header) + "." + base64url(payload) + "." + base64url(HMAC-SHA-XXX(key, header + "." + payload)). The base64url variant uses - and _ instead of + and /, and strips trailing = padding. Manually-built tokens that fail verification almost always fail here — standard base64 sneaks in if you build by hand.

Only symmetric HMAC algorithms are offered. Asymmetric signing (RS256, ES256) requires a private key whose handling is outside the scope of a paste-and-build tool — for those, generate keys with ssh-keygen / openssl and sign with a real library so you can test rotation and JWKS lookup at the same time.

Header and payload as JSON, HS256, secret = "your-256-bit-secret":

Header: { "alg": "HS256", "typ": "JWT" }
Payload: { "sub": "user_42", "iss": "https://eutils.pro", "aud": "api-staging", "exp": 1747353600, "iat": 1747267200 }
Secret: your-256-bit-secret

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzQyIiwiaXNzIjoiaHR0cHM6Ly9ldXRpbHMucHJvIiwiYXVkIjoiYXBpLXN0YWdpbmciLCJleHAiOjE3NDczNTM2MDAsImlhdCI6MTc0NzI2NzIwMH0.SIGNATURE

• Reproduce an "expired token" bug locally — set exp to a past Unix timestamp and confirm your handler returns 401 with the right message.
• Test audience validation — build a token with aud = "wrong-service" and confirm your verifier rejects it. A common bug is verifiers that ignore aud entirely.
• Forge a token that should NOT pass — flip a character in the signature and confirm verification fails. If it passes, your library is running in verify-skip mode.
• Generate a long-lived test token (exp = 4070908800, i.e. year 2099) for CI fixtures, but only with a throwaway secret unique to staging.

• exp in milliseconds instead of seconds — token "expires" in year 56,084. Verifier accepts it forever, which silently masks expiration logic.
• Custom claim with a typo — userId vs user_id vs sub — verifier reads undefined and your "feature flag claim" is never honored.
• Forgetting iat — some libraries require it for replay-window logic, some do not. Build with and without to see what your verifier tolerates.
• Mismatched typ — setting typ to "at+jwt" (access token JWT per RFC 9068) when your verifier only recognizes "JWT".

• It will not sign with RS256/ES256/PS256. Asymmetric signing needs a private key and a real crypto library; for those, use jose, jsonwebtoken, or the Web Crypto API directly.
• It will not produce JWEs. Encrypted tokens have five segments and require a recipient public key plus a content encryption algorithm.
• It will not validate that your claims make sense for a given OIDC profile. Building an id_token without sub and iat is technically valid JWS but will be rejected by spec-compliant verifiers.