JWT HS256 Generator & Verifier

Create a test HS256 token or verify one using an HMAC secret you supply. Separate signature results from time, issuer and audience checks so a valid signature is not mistaken for complete application authorization.

Browser-based · No account required · Copy and export

Open workspace Read the guide

BUILT FOR THE DETAILS

01Add your input
02Inspect & adjust
03Use your result

Browse developer tools

Workspace

Ready to use

Mode

Expiration (minutes, 0 = none)

Payload JSON

JWT token to verify

HMAC secret (never stored)

Add issued-at claim Add expiration claim

Output

HS256 uses a shared secret. This page does not support RS256, ES256, JWKS, or encrypted JWTs. Never put sensitive information in a JWT payload: it is readable by anyone holding the token.

Expected issuer, optional

Expected audience, optional

Clock tolerance (seconds)

How to use JWT HS256 Generator & Verifier

Choose generation or verification. For generation, enter a JSON object payload and choose issued-at/expiration settings.
For verification, paste the token and secret. Optionally require an exact issuer and audience and choose a clock-tolerance window.
Run locally and inspect every result field. Clear sensitive fields when finished and validate your application's remaining requirements separately.

When to use this tool

Create an HS256 test token or verify one with a shared secret. Match algorithm, issuer, audience and time checks to your application; this tool does not provide an RS256 or identity-provider validation service.

A JWT must satisfy more than its signature

HS256 uses the same secret to sign and verify. The report combines HMAC signature verification with exp and nbf checks and any explicitly requested issuer/audience checks. Audience can be a matching string or a matching member of an aud array. Clock tolerance allows a bounded number of seconds around exp and nbf; it does not bypass the signature or make an expired token indefinitely acceptable.

Worked example

Expected issuer: https://issuer.example.test
Expected audience: example-api
Clock tolerance: 0 seconds
Aggregate valid requires a valid signature and every enabled check.

Limits and output checks

HS256 compact signed JWTs only. No RSA/EC keys, JWE, key discovery, revocation lookup or authorization policy is implemented. Do not reuse a production secret for casual tests. The decoder on this site is separate and never verifies a signature. A generated token is not evidence that a service will accept it.

Reference: JWT claim validation definitions.

Frequently asked questions

Does a valid signature accept an expired token?

No. The aggregate result also enforces checked time claims, including the selected clock tolerance.

Are issuer and audience always required?

Only when you enter expected values here. A consuming application's requirements may be stricter and must be enforced there.

Does clock tolerance affect issued-at?

The tool validates NumericDate types and uses tolerance for expiration/not-before decisions. It does not implement a maximum token age or future-iat authorization policy.

HS256 verification is separate from token decoding

Choose generation or verification, use the intended sample secret and inspect checked claims and expected issuer/audience fields. Match any consuming application’s requirements separately.

Scope of this workflow

Only the documented HS256 workflow is implemented, not key discovery or authorization policy. The separate JWT Decoder does not verify signatures.

JWT Decoder - Inspect Header, Payload & Claim Dates · All developer tools · Privacy policy · Contact PixelOkay