What JWT Studio helps you do

Use one local workspace for the JWT tasks that usually get split across several utilities. Decode an existing token, inspect registered time claims, edit the header and payload, create an HMAC signature, and verify whether a token matches the secret you expect. It is built for debugging local API calls without pasting a live token into a random website.

Tokens and secrets are decoded, signed and verified in your browser with the Web Crypto API. Nothing is sent to Haivix, and no token is stored after the page is closed.

How it works

The compact token is split at its two dots, and the header and payload are decoded from Base64url into UTF-8 JSON. Registered NumericDate claims are compared with the current device time to classify the token as active, expired or not yet valid. Signing uses the Web Crypto API with HMAC and the selected hash, and verification recomputes the signature over the exact header and payload text.

How to use JWT Studio

Paste a compact JWT to decode its header and payload, then review its algorithm, registered claims, and time-based status.
Enter the expected HMAC secret to verify an HS256, HS384, or HS512 signature, or edit the JSON to create a local test token.
Sign the edited token, verify the result, and copy it into your API testing workflow.
If the API rejects it, compare iss, aud, scope and exp with the API's requirements.

When to use it

Debugging a bearer token that an API rejects.
Checking whether exp, nbf or iat explains a failure.
Creating a short-lived HMAC token for local API tests.
Comparing the header algorithm with the verifier's expectation.
Inspecting custom claims without sending the token to a third party.
Teaching how a JWT is structured during code review.

When not to use it

Verifying RS256, ES256 or other asymmetric tokens; this tool only signs and verifies HMAC.
Treating a decoded payload as proof that the token was issued by a trusted party.
Using a production signing secret in a browser on a shared machine.
Replacing server-side token validation, revocation checks or audience checks.

Example

A request returns 401 with a token that looks current. Decoding shows exp is two hours in the past, and the status badge marks it expired. A new token is signed locally with the test secret, verified, and pasted into the API client; the 401 changes to a 200 without touching production credentials.

What you can do with JWT Studio

Decode Base64url header and payload data, including Unicode claims.
Show whether exp, nbf, and iat values make a token active, expired, or not active yet.
Edit JSON and create HS256, HS384, or HS512 tokens with the Web Crypto API.
Verify HMAC signatures without uploading the token or secret.
Inspect the signing algorithm and token type from the header.
Copy the finished compact JWT for local testing.

Example: debug an API bearer token

Paste the bearer token and inspect its algorithm, issuer, audience, subject, and timing. An expired exp value or future nbf value can explain a rejected request even before signature verification.

For an HMAC token, enter the expected secret and verify the signature. If you need a local test token, edit the claims, select an HS algorithm, sign it, and copy the result into API Request Studio as a bearer token.

When a token fails verification, check that the secret matches the one used to sign it and that the algorithm in the header is the same one you selected. A valid-looking payload with a broken signature is still an invalid token.

What to know before you start

Only HS256, HS384 and HS512 are supported for signing and verification.
The status check uses the browser clock, not the server's clock or a configured skew allowance.
Decoding does not validate the token against an issuer's keys or a revocation list.
There is no key management; secrets are typed into the page for the current session.
Base64url decoding accepts standard JWT segments but does not repair malformed input.

Common mistakes

Assuming a decoded token is authentic before verifying the signature.
Choosing HS256 while the server expects a different algorithm.
Editing the payload and forgetting to re-sign the token.
Using a production secret in a browser on a shared computer.
Reading exp as milliseconds instead of Unix seconds.
Ignoring aud and iss because the signature verifies.

Troubleshooting

If decoding fails, check that the token has three dot-separated parts and that no whitespace or line break was pasted into it.

If the signature does not verify, confirm the secret and the algorithm. Changing either one changes the result.

If the token shows expired but the server accepts it, the server may allow clock skew or ignore exp. Do not rely on the client-side status alone.

If editing the payload breaks the token, remember that the signature covers the encoded header and payload. Re-sign after every change.

If the API rejects a verified token, check aud, iss, scope and revocation. Signature validity is only one part of authorization.

JWT Studio