JWT Encoder: what it does and how to use it

JWT Encoder: what it does and how to use it

By Hami Tech·April 27, 2026·Updated May 9, 2026·3 min read

Signing a JWT means taking a header and a payload, Base64url-encoding both, and producing a cryptographic signature over the joined string. The result is three segments separated by dots. Encoding is not encryption: anyone can read the payload. What signing gives you is integrity - a server that holds the matching key can prove the token was not altered after it left your hands. This encoder runs entirely in the browser via the Web Crypto API and supports the common HMAC (HS), RSA (RS), ECDSA (ES), and RSA-PSS (PS) algorithms from RFC 7518. Changes to the header, payload, algorithm, or key regenerate the token live.

You should not have to open an IDE to format a snippet from Slack, tidy a JSON blob, or check a hash. Paste it here, copy the result, move on.

JWT Encoder is a good fit when creating test tokens for local API authentication work.

The useful part

JWT Encoder is built around a few practical wins, not a long feature list:

  • Live signing with no Generate button - the token updates as you edit.
  • Full algorithm coverage: HS256/384/512, RS256/384/512, ES256/384/512, and PS256/384/512.
  • Claim helpers and date presets for common registered claims.
  • Everything stays in your browser - secrets and private keys are never uploaded.
  • Import and export header, payload, or the entire encoder configuration.

Do this, in order

  1. Edit the header. Choose the algorithm and keep typ as JWT. The alg field stays in sync with the signing dropdown.
  2. Write the payload. Add claims as JSON. Use the claim helpers for exp, iat, nbf, iss, sub, aud, and jti, including quick date presets for time claims.
  3. Provide the key. HMAC needs a secret. RSA, ECDSA, and RSA-PSS need a PEM private key - generate one in the tool or paste your own PKCS#8 key.
  4. Copy the signed token. The JWT updates as you type. Copy it, download it as a .txt file, or export the full configuration for later.

Who it is for

  • Creating test tokens for local API authentication work.
  • Prototyping OAuth or OpenID Connect claim shapes before wiring a real IdP.
  • Comparing how different algorithms affect token length and key requirements.
  • Teaching JWT structure with a visual, colour-coded token output.
  • Generating short-lived tokens with precise exp / nbf timestamps.

If you want a clean result

  • Never put passwords, API keys, or card numbers in the payload - it is only encoded, not encrypted.
  • For HMAC, prefer a long random secret (64+ characters). Use Regenerate with a chosen length.
  • For RSA and ECDSA, use PKCS#8 PEM (BEGIN PRIVATE KEY). PKCS#1 RSA keys are converted automatically.
  • Keep exp and iat as Unix seconds, not milliseconds.
  • Use Ctrl+Enter to force regenerate and Ctrl+Shift+F to pretty-format both JSON panels.

Common mix-ups

  • Treating a signed JWT as confidential. The signature does not hide the payload.
  • Using the "none" algorithm or an empty secret in production systems.
  • Mismatching the algorithm family and key type (HMAC secret with RS256, or an EC key with RS256).
  • Pasting encrypted private keys - decrypt them first; encrypted PEMs are not supported here.
  • Forgetting that exp is absolute Unix time, so a copied example timestamp may already be expired.

Private by default

JWT Encoder runs in your browser. The file or text you paste stays on your device. There is no account, and nothing is stored on a ToolBox server for this job.

If this is one step in a longer job, these usually come after it:

Open the JWT Encoder when you are ready. It is free, and you do not need an account.