JWT Debugger
About this tool
Understanding JWT structure
Every JWT consists of three parts separated by dots. The Header is a JSON object that declares the token type (typically "JWT") and the signing algorithm (such as HS256 or RS256). The Payload contains claims — key-value pairs that carry the token's data. Registered claims defined by the spec include sub (subject identifier), iat (issued-at timestamp), exp (expiration timestamp), and nbf (not-before timestamp). You can also add custom claims for application-specific data such as user roles or tenant IDs. The Signature is computed by taking the Base64URL-encoded header and payload, concatenating them with a dot, and signing the result using the algorithm specified in the header along with a secret or private key. This signature allows recipients to verify that the token has not been altered in transit.
JWT algorithm families
HMAC (HS256, HS384, HS512) is a symmetric algorithm where the same secret key is used for both signing and verification. It is the simplest to set up and works well when both the issuer and the consumer are the same service or share a trusted secret. RSA (RS256, RS384, RS512) uses asymmetric key pairs — a private key signs the token and a corresponding public key verifies it. This is ideal when tokens are issued by an authorization server and verified by multiple independent services that only need the public key. ECDSA (ES256, ES384) uses elliptic curve cryptography to provide equivalent security to RSA with significantly smaller key sizes, reducing both token size and computational cost. RSA-PSS (PS256, PS384, PS512) is a probabilistic variant of RSA with stronger formal security proofs than the deterministic PKCS#1 v1.5 padding used by standard RSA signatures, making it the preferred choice for high-security environments.
JWT security best practices
Never store sensitive data such as passwords, credit card numbers, or personal identifiers in the JWT payload. The payload is Base64URL-encoded, not encrypted — anyone who intercepts the token can decode and read the claims. Always verify the signature before trusting a token's contents; decoding alone does not prove authenticity. Use short expiration times (minutes to hours, not days or weeks) to limit the window of misuse if a token is leaked. Implement key rotation on a regular schedule so that compromised keys have a limited blast radius. Avoid sending production tokens to online JWT tools that transmit data to a server, as your tokens could be logged or intercepted. This tool is safe to use with real tokens because all processing happens client-side in your browser using the Web Crypto API — no network requests are made.
Related tools
Use the Code Diff tool to compare JWT payloads side by side when debugging token changes across environments. The ID Toolkit can decode other token and identifier formats such as UUIDs, ULIDs, and Snowflake IDs.
Frequently Asked Questions
What is a JSON Web Token (JWT)?
A JWT is a compact, URL-safe token format defined in RFC 7519 for securely transmitting claims between parties. It consists of three Base64URL-encoded parts separated by dots: a header specifying the algorithm and token type, a payload containing claims (such as sub, iat, exp, and custom fields), and a cryptographic signature that ensures integrity. JWTs are widely used in OAuth 2.0 authorization flows, OpenID Connect identity layers, and API authentication schemes. Unlike traditional session-based authentication where the server stores session state, JWTs enable stateless authentication because all the necessary information is embedded in the token itself. This makes them particularly efficient in distributed microservice architectures where multiple services need to validate requests independently without querying a central session store.
How do I decode a JWT?
Paste your JWT into the encoded token field at the top of the page. The header and payload are decoded from Base64URL and displayed instantly in separate editable panels. Decoding simply means reversing the Base64URL encoding to reveal the JSON content — it does not require a secret key, because the payload is encoded but not encrypted. This is an important distinction: anyone with access to a JWT can read its claims. Verification, on the other hand, uses a secret or public key to confirm the signature is valid and the token has not been tampered with. You can also edit the header or payload JSON directly and the encoded token will update in real time. To re-sign the modified token, enter your secret or private key and click the Sign button to generate a new valid signature.
Is it safe to paste my JWT here?
Yes. All decoding, verification, and signing happens entirely in your browser using the Web Crypto API. No tokens, keys, or any other data are transmitted to any server — you can verify this by opening your browser's network tab and observing that no requests are made when you interact with the tool. This is a critical advantage over many server-side JWT debugging tools, which require you to send your token to a remote endpoint for processing. Sending production tokens to third-party servers creates a security risk because those tokens could be logged, intercepted, or misused. With this client-side tool, your sensitive tokens and signing keys never leave your machine. For additional peace of mind, the tool works fully offline once the page has loaded, so you can disconnect from the internet before pasting particularly sensitive tokens.
What algorithms are supported?
This tool supports four algorithm families: HMAC (HS256, HS384, HS512) uses a shared symmetric secret for both signing and verification, making it simple to set up but requiring both parties to possess the same key. RSA (RS256, RS384, RS512) uses asymmetric public/private key pairs with PKCS#1 v1.5 padding, allowing you to sign with a private key and verify with a widely distributed public key. ECDSA (ES256, ES384) uses elliptic curve cryptography to achieve equivalent security with significantly smaller key sizes, which reduces token overhead. RSA-PSS (PS256, PS384, PS512) is a probabilistic variant of RSA with stronger security proofs than PKCS#1 v1.5. For most applications, RS256 is recommended as it is the most widely supported algorithm across JWT libraries and identity providers.
Standards & References
All processing happens in your browser. No tokens are sent to any server.