Skip to content
JWTForge

How JWTForge works & privacy

The short version: everything runs in your browser, and the Audit tab shows signals to verify — never confirmed vulnerabilities.

The client-side guarantee

Every operation — decoding, claim parsing, signature verification, key generation, signing, and the HS256 brute-force — runs in JavaScript in your browser tab using the native WebCrypto API. Your token, secrets, and keys never leave the page.

You can verify this yourself: open your browser's DevTools → Network tab, paste a token, and exercise every feature. You will see no outbound request carrying your token, secret, or keys.

The one exception: JWKS fetch

The Decode tab has an optional, opt-in feature to fetch a JWKS from a URL you type, so you can verify a signature against a published key set. This is the only outbound request the app makes with your input, it is clearly labeled, and it sends only the URL you provide — never your token. It runs client-side and may be blocked by the remote server's CORS policy.

Analytics

JWTForge uses Vercel Web Analytics for aggregate visit counts only. It is cookieless, stores no personal data, and never reads form or input values — so it cannot see your token, secret, or keys. As an extra safeguard, the URL reported to analytics is stripped of the #t= token fragment before any event is sent, so a token in a shared link is never transmitted.

Why there is no built-in request sender

The Attack tab deliberately does not fire requests at targets. A hosted proxy that relays attacker-supplied requests would turn this site into an SSRF / open-proxy liability and would break the privacy guarantee. Instead, JWTForge generates the forged tokens and ready-to-run artifacts (curl, .http, Burp Intruder payloads, a nuclei template, and the equivalent jwt_tool command) that you run from your own authorized environment.

Audit ≠ confirmed vulnerability (read this)

A purely client-side tool cannot tell you whether a server is actually vulnerable. Whether a server accepts alg:none, mishandles algorithm selection, or uses a weak secret is a property of the server's code — invisible from the token alone.

So the Audit tab never says a token “is vulnerable.” Each signal is a hypothesis to verify, paired with how to actually test it. The proof comes from running the matching Attack-tab artifact against a system you are authorized to test.

Threat model & responsible use

JWTForge is built for pentesters, bug bounty hunters, and AppSec engineers doing authorized work. Forging tokens and testing them against systems you do not own or lack written permission to test is illegal in most jurisdictions. You are solely responsible for how you use the generated artifacts.

Supported algorithms

Verification and signing support HS256/384/512 (HMAC), RS256/384/512 (RSASSA-PKCS1-v1_5), PS256/384/512 (RSA-PSS), and ES256/384/512 (ECDSA), all via WebCrypto. Encrypted tokens (JWE, 5-segment) are not decoded.