[Tool #91] JWT Workbench leaves alg as HS256 in the editable header after HS384 encoding

[baixiangcpp]

Summary

JWT Workbench signs a token with HS384 when that algorithm is selected, but the editable Header JSON remains set to HS256.

Affected tool: JWT Workbench
Route: https://byteflow.tools/en/jwt-workbench
Observed during browser acceptance: 2026-08-18

Reproduction

1. Open the affected route.
2. Select HS384 as the signing algorithm.
3. Use this header JSON:

{
 "alg": "HS256",
 "typ": "JWT"
}

4. Keep the sample payload and a valid signing secret.
5. Click Encode.
6. Compare the editable Header JSON, generated token, and Decoded Header.

Actual output

• The generated JWT is signed using HS384.
• Decoded Header reports alg as HS384.
• The editable Header JSON still shows alg as HS256.

The signing result and decoded result disagree with the header currently shown as editable input.

Expected output

When HS384 is selected and Encode is clicked, the editable header should be synchronized to alg HS384, or the UI should clearly treat alg as derived/read-only from the algorithm selector. The header shown to the user must not remain HS256 while the generated token uses HS384.

Impact

Users can edit or copy a header that does not describe the token they just generated. This is confusing when debugging JWT interoperability or verifying the selected algorithm.

Regression coverage

Encode with HS256, HS384, and every supported algorithm. Assert that the selected algorithm, editable header, generated token header, decoded header, and verification path remain consistent.