JWT Encoder/Decoder

About the JWT Encoder/Decoder

A JWT is really just a base64url-encoded header and payload, dot-separated, with a signature computed over both. Paste one in and it decodes locally so you can inspect the claims, and if you supply the secret it'll verify or generate an HS256 signature too, all without a network request.

A critical distinction: JWTs are encoded, not encrypted

This is worth stating plainly because it's a genuinely common misconception: the header and payload of a JWT are just base64url-encoded JSON, readable by anyone who copies the token, with no secret or key required at all. That's exactly why decoding works instantly the moment you paste a token in here, no secret needed. The secret only comes into play for the signature, which exists purely to prove the token wasn't tampered with after it was issued, integrity, not confidentiality. Never put sensitive information you wouldn't want exposed directly in a JWT's payload, anyone who intercepts the token, whether or not they know the signing secret, can read every claim inside it.

Why base64url instead of standard base64

Standard base64 uses +, /, and trailing = padding characters, all of which have special meaning inside URLs and HTTP headers, + can be interpreted as a space, / looks like a path separator, and = often marks query-string boundaries. Since JWTs are routinely passed in URLs, cookies, and Authorization headers, standard base64 would require additional escaping to travel safely through those contexts. Base64url swaps + for -, / for _, and drops the padding entirely, producing an encoding that's safe to use directly in a URL or header with no further escaping needed.

Why this tool uses the browser's native Web Crypto API instead of hand-rolled HMAC

Unlike some of this site's other tools that implement their own parsers and tokenizers from scratch, HMAC-SHA256 signing and verification here go through crypto.subtle, the browser's built-in, standardized cryptographic API, rather than a JavaScript reimplementation of the HMAC algorithm. That's a deliberate choice: cryptographic primitives are notoriously easy to get subtly wrong by hand, timing differences, incorrect padding, off-by-one errors in the hashing rounds, in ways that can silently weaken the security guarantee without being obviously broken. Using the browser's own audited, native implementation means the actual cryptographic math is handled by code that's been reviewed and tested far more rigorously than a one-off hand-written version could be.

Why only HS256 is supported for signature verification

The Verify Signature panel only appears when the decoded header's alg field is HS256, because HS256 (HMAC with SHA-256) is a symmetric algorithm, the same shared secret is used to both create and verify the signature. Algorithms like RS256 or ES256 are asymmetric instead, signed with a private key and verified with a mathematically related but different public key, typically supplied as a certificate rather than a plain text secret. Supporting those would need an entirely different input (a public key, not a shared secret) and a different Web Crypto API call shape, which is why this tool focuses specifically on the HS256 case most commonly seen in smaller applications and API tokens.

A practical caution worth repeating even for a local-only tool

Everything here runs entirely client-side with no network request, which is true and worth trusting for this specific tool. Even so, it's good general practice never to paste a real, live production JWT or its actual signing secret into any web-based tool, including this one, when testing or debugging. Use example tokens and placeholder secrets for experimentation, and if you need to inspect a genuine production token, prefer decoding it in a local script or your own trusted tooling instead, simply as a matter of good security hygiene rather than any specific concern about this particular page.