JWT Crafter
Sign and verify JWTs with HS256/384/512 or RS256/384/512 keys.
Overview
Build a JSON Web Token from scratch - pick the algorithm (HS256/384/512 for HMAC, RS256/384/512 for RSA), paste the secret or private key, supply the header and payload as JSON, and sign. The same tool verifies a token against a key, distinguishing "invalid signature" from "expired" or "wrong issuer."
It's for backend developers integrating with OAuth/OIDC providers, building authentication flows, or debugging an SSO handshake. Reach for it when reproducing a token a server expects, validating a third-party JWT, or generating fixed test tokens that integration tests can rely on.
How it works
JWT (RFC 7519) is a compact format: three base64url-encoded segments joined by dots. The first is the header ({"alg":"HS256","typ":"JWT"}), the second is the payload (any JSON), the third is the signature over header.payload using the algorithm declared in the header.
HMAC algorithms (HS256/384/512, per RFC 7518) take a shared secret. RSA algorithms (RS256/384/512) sign with a PKCS#8/PEM private key and verify with the matching public key. Standard claims (iss, sub, aud, exp, nbf, iat, jti) are recognised but their content is up to the user.
Examples
- Header + payload + secret (HS256):
Header: {"alg":"HS256","typ":"JWT"} Payload: {"sub":"user-1","exp":1735689600} Secret: hunter2 Token: eyJhbGciOi.eyJzdWIi.signature... - Verify a token:
Paste token + secret -> "Signature valid; exp=2025-01-01T00:00Z" - RS256 with PEM key:
-----BEGIN RSA PRIVATE KEY----- MIIEowIBAAKCAQEA... -----END RSA PRIVATE KEY----- - Expired token:
"Signature valid but token expired (exp was 2024-01-01)"
FAQ
Should I use HS256 or RS256?
HS256 is simpler (one shared secret) but requires the verifier to know the signing key - fine for internal services. RS256 lets verifiers check tokens with just a public key, which is standard for OIDC providers issuing tokens to many consumers.
What's the difference between exp and nbf?
exp is "expires at" (the token is invalid after this Unix timestamp). nbf is "not before" (invalid until this timestamp). Both are optional but commonly used together.
Why does my token fail verification?
Common causes: wrong secret/key, the token was signed with a different algorithm than your verifier expects, or clock skew makes exp look expired. Check the header's alg matches what you're verifying against.
Is none algorithm supported?
JWTs with alg: none are signature-less and dangerous - many libraries refuse them by default. The crafter accepts none for educational use but flags it as unsafe.