Skip to main content
Bethemesh
Security & privacy

JWT Encoder

Generate an HMAC-signed JSON Web Token for testing: enter the header and payload as JSON, pick HS256, HS384 or HS512 and your secret; alg and typ are filled in automatically.

  • Clipboard

Embed this widget

Customize the result, check the live preview, then copy the code.

Preview

Embed code type

Code to copy

Responsive and automatically resized by Bethemesh.

Algorithm

For testing and development: do not use a production secret on a shared or untrusted device.

Was this tool useful?

How does this tool work?

The JWT encoder builds an HMAC-signed token from a header, a JSON payload and a shared secret. It is meant for developers and testers who need a custom token to call a local API, write an automated test or reproduce an edge case (expired token, missing role). It is designed for development and testing, not for issuing production tokens.

The tool checks that the header and payload are valid JSON objects, then sets alg in the header to the chosen algorithm and typ to JWT. Each object is serialized and Base64URL-encoded (RFC 4648, without = padding), and the two segments are joined by a dot. For example, the header {"alg":"HS256","typ":"JWT"} becomes eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.

The signature is an HMAC computed over the "header.payload" string with SHA-256, SHA-384 or SHA-512 depending on the algorithm (RFC 7518, section 3.2), using the Web Crypto API. The Base64URL-encoded result is the third segment of the JWT (RFC 7519). RFC 7518 requires a key at least as long as the hash output: 256 bits (32 bytes) for HS256, 384 bits for HS384 and 512 bits for HS512. The exp, iat and nbf dates in the payload must be Unix seconds, for example "exp": 1767225600 for January 1, 2026 at 00:00 UTC.

How to use this tool

  1. Write the header and payload

    Edit the two prefilled JSON areas or import a .json file. Add your claims: sub, iss, aud, exp, roles or custom fields.

  2. Choose the algorithm and secret

    Select HS256, HS384 or HS512 and enter the shared secret. The alg and typ header fields are updated automatically.

  3. Generate and copy the JWT

    Click Generate: the signed token appears and can be copied. An error is shown if the JSON is invalid or the secret is empty.

JWT HMAC signature

JWT HMAC signature

JWT = Base64URL(header) + '.' + Base64URL(payload) + '.' + Base64URL(HMAC(secret, signing input))

Use cases

Test a protected API locally

Create a token signed with your development environment’s secret to call a protected route with curl or Postman, without going through the whole login flow.

Reproduce an expired or role-less token

Set exp in the past or remove a roles claim to check that your middleware really returns a 401 or 403 error in these edge cases.

Prepare test fixtures

Generate stable tokens for your integration tests, then check them with the JWT verifier to make sure the secret and claims match what the server expects.

Examples

JWT signed with HS256

Input

Algorithm: HS256; JSON header: {"alg":"HS256","typ":"JWT"}; JSON payload: {"sub":"1234567890","name":"John Doe","iat":1516239022}; Secret: test-secret

Result

Signed JWT: three dot-separated Base64URL segments; the signature uses HMAC-SHA256.

Tips and best practices

  • Use a secret of at least 32 random bytes for HS256: a short word such as "secret" makes the token crackable by offline brute force.
  • Write exp and iat in seconds, not milliseconds: JavaScript’s Date.now() returns milliseconds and yields a date around the year 58,000.
  • Never put confidential data in the payload: it is only Base64URL-encoded and readable by anyone who holds the token.

Sources and references

Frequently asked questions

How do you create a JWT?

A JWT is built by Base64URL-encoding a JSON header and a JSON payload, then signing the "header.payload" string with the chosen algorithm. Here you just enter both objects and a secret, then click Generate. In production this is done by your authentication server or a library such as jose or jsonwebtoken.

How long should an HS256 secret be?

RFC 7518 requires a key of at least 256 bits, that is 32 bytes, for HS256; 48 bytes for HS384 and 64 bytes for HS512. A random secret of that size, for example from a secure token generator, prevents dictionary attacks on the signature.

Why only HS256, HS384 and HS512?

These HMAC algorithms only need a shared secret, which is enough to create test tokens. RS256 or ES256 would require a private key, which should not be handled in a web tool. If several parties must verify your tokens without being able to issue them, use an asymmetric algorithm on the server.

How do I add an expiration date to a JWT?

Add the exp claim to the payload with a Unix timestamp in seconds, for example "exp": 1767225600. A timestamp converter helps you compute that value from a date. Also consider iat to record when the token was issued.

Can I use these tokens in production?

No, the tool is designed for development and testing. In production, tokens must be issued by a server that keeps the secret away from users, enforces short lifetimes and handles key rotation.

Is my secret sent anywhere?

No. Encoding and the HMAC signature are computed in your browser with the Web Crypto API, without any network request. Still avoid entering a production secret, because anyone who knows it can sign tokens your API will accept.

Recommended workflow

Continue your processing

Discover tools that naturally fit before, after, or alongside this one.

Works well with

JWT Decoder

Decode a JWT to read its header, payload, claims and expiration dates.

Security & privacyFeaturedUse this tool

Next step

JWT Signature Verifier

Verify a JWT signature with an HMAC secret or a JWK, JWKS or PEM public key, then check exp, nbf, iss and aud.

Security & privacyUse this tool

Read next