JWK Thumbprint Calculator
Compute an RFC 7638 thumbprint for a JSON Web Key — the canonical fingerprint used as a stable kid value
e, kty, and n, in that lexicographic order, with no whitespace. That makes the thumbprint stable regardless of what optional fields (kid, use, alg) the same key happens to carry — which is exactly why it's commonly used as the kid.About this tool
The ToolNinja JWK Thumbprint Calculator computes the RFC 7638 canonical thumbprint for a JSON Web Key — a deterministic fingerprint derived by hashing only the required members for that key's type, in a fixed lexicographic order, with no whitespace. For an RSA key that means hashing exactly {"e":...,"kty":"RSA","n":...} — nothing else. Any optional fields the key carries (kid, use, alg, x5c) are excluded entirely, which is exactly what makes the thumbprint useful: two JWK representations of the same underlying key always produce the same thumbprint regardless of which optional metadata happens to be attached, so it's commonly used as the kid value itself, or to confirm two differently-formatted JWKs actually represent the same key. Supports RSA, EC (any curve), oct (symmetric), and OKP (Ed25519/X25519) keys, with SHA-256, SHA-384, or SHA-512 as the hash. Everything runs 100% in your browser via the Web Crypto API — your key material never leaves your machine.
When to use it
- →Generating a stable kid for a JWKS endpoint so key rotation doesn't require hand-assigning IDs
- →Confirming that a JWK you received matches a key you already have, without comparing every field manually
- →Debugging a 'key not found' error in a JWT verification flow by comparing the expected vs. actual kid
- →Computing the thumbprint required by DPoP (RFC 9449) or other specs that bind a token to a specific key
Tips
- ◆The thumbprint depends only on the required members (e/n for RSA, crv/x/y for EC) — changing kid, use, or alg on the same key never changes its thumbprint.
- ◆SHA-256 is overwhelmingly the standard choice (it's what most kid-generation conventions and DPoP implementations use) — only switch hash algorithms if a spec you're implementing explicitly calls for a different one.
- ◆The 'canonical JSON that was hashed' panel shows exactly what went into the hash — useful for debugging a thumbprint mismatch against another implementation.
Frequently asked questions
Why use a JWK thumbprint instead of just picking a random kid?
A thumbprint is deterministic — the same key always produces the same thumbprint, from any JWK representation of it. That lets two systems that both have the same key (but received it through different channels, or with different optional metadata attached) independently compute matching identifiers, with no coordination needed.
Does changing the 'alg' or 'use' field in a JWK change its thumbprint?
No. RFC 7638 defines the thumbprint input as only the required members for the key type (kty plus the key-material fields) — optional fields like alg, use, kid, and x5c are deliberately excluded from the hash, precisely so the thumbprint identifies the cryptographic key itself, not its metadata.
Is a JWK thumbprint the same as a certificate fingerprint?
They're conceptually similar (both are a hash-based fingerprint of key material) but computed differently and not interchangeable. A certificate fingerprint typically hashes the DER-encoded X.509 certificate; a JWK thumbprint hashes a specific canonical JSON serialization defined by RFC 7638. Don't compare one against the other expecting a match.