Do I need a key just to see the header and payload?

No. A JWT's header and payload are only base64url-encoded, not encrypted, so anyone can decode and read them without any key at all. A key (or secret) is only needed to verify the signature, which is the part that actually proves the token wasn't tampered with.

Why does verification need a public key instead of the private key for RS256/ES256?

Verifying a signature only requires the public half of an RSA or ECDSA key pair; the private key is only needed to create the signature in the first place. This tool never asks for or handles a private key, which is why it can safely support RS256/384/512 and ES256/384 verification.

What does a signature 'valid' result actually prove?

It proves the token's header and payload haven't been altered since it was signed with the key or secret you provided, and that whoever signed it possessed that key or secret. It says nothing about whether the claims inside (like an expiry or a role) are ones you should trust for your specific use case; check those separately.

Does this tool send my token, secret, or public key anywhere?

No. Decoding and verification both happen entirely in your browser via the Web Crypto API and @noble/hashes; nothing is transmitted.

JWT Debugger - Decode and Verify a JSON Web Token

Overview

Introduction

A JWT's payload is visible to anyone who has the token, since it's only encoded, not encrypted, but confirming it's genuine requires actually checking the signature.

This tool decodes any token's header and payload immediately, and verifies its signature when you supply the matching secret or public key, entirely in your browser.

What Is JWT Debugger & Signature Verifier?

A JWT decoder and signature verifier: decoding works on any well-formed token with no key needed, since header/payload are just base64url-encoded JSON; verification checks the signature against a secret (HMAC algorithms) or a public key (RSA/ECDSA algorithms).

It supports the algorithms actually used, HS256/384/512, RS256/384/512, and ES256/384, reporting which one a token's header declares before you attempt verification.

How JWT Debugger & Signature Verifier Works

The token is split on its two dots into header, payload, and signature segments; the first two are base64url-decoded and parsed as JSON and shown immediately, regardless of whether you provide a key.

If you provide a secret or public key, verification recomputes the expected signature (HMAC for HS*, or `crypto.subtle.verify()` for RS*/ES* after importing your PEM as an SPKI public key) and compares it against the token's actual signature segment.

When To Use JWT Debugger & Signature Verifier

Use it to inspect what claims a JWT actually contains, when debugging an authentication flow or an API integration that uses bearer tokens.

It's also useful for confirming a token was genuinely signed by the party you expect, given their public key or your shared secret.

Often used alongside JWT Builder, RSA/ECDSA Key Generator and HMAC Generator.

Features

Advantages

Decodes any token immediately, with no key required, since that part of a JWT needs none.
Supports signature verification for both HMAC and public-key algorithms, covering the algorithms JWTs actually use in practice.
Never requires or handles a private key, only public keys for RS*/ES* verification, which is all verification ever needs.

Limitations

Doesn't check claim semantics like expiry (`exp`) or audience (`aud`) against the current time or your expected values; it only decodes and verifies the signature.
"none" algorithm tokens (unsigned JWTs) aren't supported for verification, since there's nothing cryptographic to check.

Examples

Decoding a token's payload

Input

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJhYmMxMjMifQ.signature

Output

{"sub": "abc123"}

The middle segment is base64url-decoded and parsed as JSON, revealing the payload without needing any key.

A signature mismatch

Input

a valid-looking token, but the wrong secret entered

Output

Signature: invalid

Recomputing the HMAC with the wrong secret produces a different value than the token's actual signature, so verification correctly reports it as invalid.

Best Practices & Notes

Best Practices

Always verify a token's signature before trusting any claim inside it for anything security-relevant; a decoded-but-unverified payload could have been altered.
Check the algorithm in the decoded header matches what you expect before verifying; accepting whatever algorithm a token claims (the classic "alg confusion" attack) is a real vulnerability class in JWT libraries.
Cross-check time-based claims (`exp`, `nbf`, `iat`) against the current time yourself; this tool doesn't evaluate them for you.

Developer Notes

HMAC verification recomputes the signature with `@noble/hashes/hmac.js` and does a full-length equality check (not intended as a hardened constant-time comparison, this is a debugging tool, not a production auth library). RS*/ES* verification imports the provided PEM as an SPKI public key via `crypto.subtle.importKey()` and calls `crypto.subtle.verify()`; ES256/384 rely on the Web Crypto API's IEEE P1363 (raw r‖s) ECDSA signature format, which is exactly the format JWTs use, so no DER conversion is needed.

JWT Debugger & Signature Verifier Use Cases

Inspecting the claims inside a JWT while debugging an authentication or API integration
Verifying a token was genuinely signed by an expected party, given their shared secret or public key
Checking which algorithm a third-party token actually uses before writing verification code for it

Common Mistakes

Trusting a decoded payload's claims without verifying the signature first; decoding alone proves nothing about authenticity.
Verifying against a private key instead of the corresponding public key for RS*/ES* algorithms; verification only ever needs the public half.

Tips

If verification fails unexpectedly, double check you selected the right key: HS* algorithms need the shared secret, while RS*/ES* need the public key, not the private key.

JWT Debugger & Signature Verifier