How to Encode and Sign a JWT in Your Browser

You need a test JWT to plug into a request while debugging an API, but writing a script just to call a JWT signing library for one throwaway token is a lot of setup for something you’ll use once and discard. Sometimes it’s the reverse problem — you have a token and need to see exactly what’s inside it before deciding whether it’s the source of a bug.

Both directions — decoding an existing token and minting a new signed one — are common enough during API development and debugging that having both in one place, without needing backend code for either, saves real setup time.

What encoding and signing a JWT actually involves

Encoding a JWT means taking a JSON payload, combining it with a header specifying the algorithm, and producing the three base64url-encoded, dot-separated segments that make up a token. Signing is the part that makes the token trustworthy: for HS256, the header and payload are hashed together with a secret using HMAC-SHA256, producing a signature that proves the token wasn’t tampered with by anyone who doesn’t know that secret.

The Web Crypto API — a browser-native cryptography interface — can perform this HMAC signing directly in JavaScript running in your browser, without needing a server-side library or backend endpoint to do the actual cryptographic work.

Why people get stuck here

• Minting a one-off test token usually means writing throwaway code. Without a browser-based tool, testing an API that expects a JWT often means writing a small script just to call a signing library once.
• Confusing encoding with signing. Encoding structures the data into the JWT format; signing is the cryptographic step that makes the token verifiable — treating them as the same step can lead to producing tokens that look right but aren’t actually properly signed.
• HS256’s shared-secret model has a specific trust assumption. Anyone who knows the secret can both sign and verify tokens, which is different from asymmetric algorithms — using the wrong mental model here can lead to security mistakes in a real system.
• Test secrets sometimes leak into places they shouldn’t. Using a tool that sends your secret to a remote server for a “test” token carries more risk than it should for something meant to stay local to your debugging session.

What a good JWT encoder/decoder looks like

Covers both directions: decode and encode/sign

Being able to both inspect an existing token and mint a new signed one from scratch in the same tool covers the two most common JWT tasks during API development.

Uses the Web Crypto API for real HS256 signing

Producing an actually validly signed token, not just a JWT-shaped string, means the test token will genuinely pass signature verification on the receiving end.

Runs entirely client-side, keeping your secret local

Since HS256’s security depends on the secret staying private, a tool that never sends it to a remote server is meaningfully safer for testing with real or realistic secrets.

Common mistakes to avoid

• Assuming a JWT-shaped string is automatically validly signed, when the signature specifically needs to be produced with the correct algorithm and secret.
• Reusing a real production secret in a browser-based testing tool without confirming it processes everything locally.
• Confusing the header’s specified algorithm with what’s actually used to sign — a mismatch here produces a token the receiving system will reject.
• Forgetting that HS256’s shared secret means anyone with that secret can also mint valid tokens, not just verify them — a different trust model than asymmetric signing.

How to do it with JWT Encoder / Decoder

Online Tool Store’s JWT Encoder / Decoder decodes a JWT’s header and payload, or encodes and signs a new HS256 token from JSON and a secret, using the Web Crypto API, entirely in your browser.

1. To decode: paste an existing token to see its header and payload as readable JSON.
2. To encode: enter your payload JSON and a secret.
3. Generate the signed HS256 token.
4. Use the token to test an API endpoint that expects JWT-based authentication.

Because it uses the Web Crypto API for real HS256 signing entirely client-side, you get a genuinely valid test token without writing throwaway signing code or sending your secret anywhere.

Frequently asked questions

Is a token created this way a real, validly signed JWT?

Yes — the tool uses the Web Crypto API to actually perform HMAC-SHA256 signing with your provided secret, producing a token that will pass signature verification on a system using the same secret, not just something that looks like a JWT.

Is it safe to use a real secret to test with this tool?

As long as the tool processes everything client-side without sending your secret to a remote server, it stays local to your browser session — but it’s still good practice to use a dedicated test secret rather than a production one wherever possible.

What’s the difference between HS256 and other JWT signing algorithms?

HS256 uses a single shared secret for both signing and verifying, meaning anyone with that secret can do either. Asymmetric algorithms use a private key to sign and a separate public key to verify, which is a different trust model better suited to some systems.

Final thought

Minting or inspecting a JWT for testing doesn’t need backend code — a browser-based tool using real Web Crypto API signing covers both directions safely and quickly. Just keep your secret handling deliberate, even for test tokens.

Try the free JWT Encoder / Decoder