JWT Tool (Decode / Verify / Sign)

JSON Web Tokens are the de-facto authentication primitive of the modern web, and yet a surprising number of developers using them every day don't fully understand the structure beyond 'I get a string back from the auth endpoint and put it in the Authorization header on subsequent requests'. The token itself is three Base64URL-encoded segments separated by dots — a header describing the signing algorithm and key identifier, a payload containing the claims about the user or session, and a signature proving the token was issued by a holder of the signing key. The genius and the curse of the format is that the first two parts are trivially readable by anyone who can decode Base64URL; the security depends entirely on the signature, not on the contents being secret.

Decoding a JWT to inspect its contents is the first thing most developers want to do when handed an unfamiliar token, and it's a perfectly safe operation as long as you remember that decoding is not the same as verifying. The tool here decodes the header and payload with clear formatting, displays the standard claims (iss, sub, aud, exp, nbf, iat, jti) with appropriate type hints, and shows an 'expires in' countdown for time-sensitive claims so you can immediately see whether a token is still valid in wall-clock terms. Custom claims show up as labelled JSON, which makes spotting application-specific data straightforward.

Signature verification is where the security actually lives, and the tool's strict-mode verifier exists specifically because most public JWT libraries have been the source of authentication bypasses over the years through subtle algorithm-related bugs. The 'alg=none' bypass — where a token claims no algorithm and naive verifiers accept it as valid — has been responsible for high-profile breaches at companies that should have known better. The strict mode here rejects alg=none unconditionally, requires an allowlist of acceptable algorithms before verifying, and prevents key/algorithm confusion (using an RSA public key as the HMAC secret for HS256, for example, is a classic exploit pattern that strict mode blocks).

The supported algorithms cover the full real-world JWT spectrum. HS256/HS384/HS512 (HMAC with SHA-2) are symmetric — same secret on both sides — and used heavily in machine-to-machine APIs where the consumer holds a shared secret. RS256/RS384/RS512 (RSA with PKCS1.5) and PS256/PS384/PS512 (RSA-PSS) are asymmetric — public key for verification, private key for signing — and used heavily in OIDC and federation scenarios where consumers shouldn't be able to forge tokens. ES256/ES384/ES512 (ECDSA) are the modern asymmetric option, smaller signatures and faster verification than RSA. The right algorithm depends on the threat model and the trust relationship between issuer and consumer.

JWKS support matters for any production JWT verification because it's how rotating-key systems work in practice. A JWKS endpoint exposes the issuer's current public keys as a JSON document; consumers fetch it, find the key matching the kid (key ID) in the token's header, and verify against that specific key. The tool here can fetch a JWKS from a URL or accept a pasted JWKS document, automatically picks the right key by kid, and shows which key was used. Auth0, Okta, Google Identity Platform, AWS Cognito, and most other identity providers expose JWKS endpoints; supporting them properly is the difference between a tool that works on toy examples and one that handles real auth flows.

Token creation is the half of JWT work that gets less attention than decoding and verification but matters enormously for testing. Building reproducible test fixtures with specific claim values, expiration times, and signatures is what makes integration tests reliable. The signing path here accepts a secret or private key, signs the token with the chosen algorithm, and produces a token byte-for-byte identical to what the real issuer would produce given the same inputs. For developers writing tests against authentication-protected endpoints, this is far better than mocking the auth check entirely — the tests exercise the same verification code that production runs.

The exp claim is the single most common source of JWT-related bugs in practice. exp is a Unix timestamp in seconds (not milliseconds, which is the JavaScript native time format and a common cause of off-by-1000 errors), and the verifier should reject tokens whose exp has passed. Subtle issues come from clock skew between issuer and consumer, from caching that delays the recognition of expiration, and from libraries that don't enforce exp by default. The strict-mode verifier here checks exp, nbf (not before), and iat (issued at) with configurable clock skew tolerance, which catches most of the timing-related issues at the source.

Common pitfalls include treating tokens as encryption rather than signatures (anyone can read a JWT, the signature only proves authenticity), storing tokens in localStorage where XSS attacks can read them (the better pattern is httpOnly cookies for browser tokens), embedding sensitive data in claims (PII, internal user identifiers, anything that shouldn't be visible to the token holder), and using HS256 with a weak shared secret (which lets an attacker brute-force the secret given a single token). The tool here doesn't enforce these patterns directly but the documentation around it makes the issues visible during development, which is the right time to address them.

Privacy and operational notes. Token contents are processed entirely in the browser using WebCrypto; there's no server-side handling of the user's tokens, secrets, or keys. JWKS fetches go directly from the browser to the JWKS URL, with no proxy through this site's servers. For developers handling production tokens (which often contain real user data), this matters because uploading sensitive material to a third-party tool defeats the purpose of having a debugger; the browser-side model means the tool can be used in production debugging without creating new exposure paths.

Operationally the tool is one workspace combining decoder, verifier, and signer. Paste a token to decode and inspect, paste a key or fetch a JWKS to verify, configure strict mode and allowed algorithms, see verification status with clear pass/fail indicators. For signing, configure header and payload, choose an algorithm, provide the appropriate key, get the signed token. Multiple tokens can run through the same session, useful when chasing down an authentication bug across a series of related tokens rather than handling a single one-off case. The interface is responsive, the operations are fast, and nothing leaves the browser that you didn't explicitly send out (like a JWKS URL fetch).

OAuth 2.0 and OIDC integrations are where this tool gets used heaviest in practice. A typical OIDC flow involves an authorization code, a token exchange, and a series of access and ID tokens that need to be inspected during integration to confirm the right claims are present, the right audience is set, and the signature verifies against the issuer's published JWKS. Without a tool, this debugging happens with a stack of curl commands, a JSON formatter, and a separate signature verifier — slow, error-prone, and frustrating during the time pressure of an integration deadline. With this tool, the same workflow collapses into paste-decode-verify, which means an OIDC integration debugging session takes minutes rather than hours.

Refresh token handling is a related concept worth touching because it's adjacent to JWT work and frequently confused with it. Refresh tokens are typically opaque strings rather than JWTs — the auth server treats them as session pointers rather than self-contained credentials — but the same auth flow produces both, and developers occasionally try to decode a refresh token expecting it to be a JWT and getting confused when the decode fails. The tool here clearly indicates when a token is not a valid JWT structure rather than producing misleading output, which catches this category of confusion at the right moment.

Standard claim semantics deserve a brief mention because misuse of standard claims is a recurring source of subtle bugs. iss is the issuer URL and should be checked against an expected value, not just present. aud is the intended audience, and tokens should reject themselves on the wrong service even if the signature is valid. sub is the subject (typically the user identifier) and should be the primary user identity for application logic. The exp/nbf/iat trio governs token lifetime. jti is the token ID and is occasionally used for revocation lists. Treating these as 'just claims' rather than as semantically significant fields with specific verification expectations is the source of authentication bypasses where a token from one service gets accepted by another.