PGP Public Key Inspector

How to use

1. Paste an armored public key block, or drop a .asc or .gpg file onto the box.
2. Compare the full fingerprint — all forty hex digits — against the one published by whoever owns the key.
3. Check the creation and expiry dates; an expired key cannot verify signatures made after it lapsed.
4. Read the user IDs to see which names and addresses the key claims, and the subkey list to see which key actually signs or encrypts.
5. Anything in amber is worth resolving before you trust the key.

Frequently asked questions

Why compare the fingerprint instead of the key ID?

Because the short key ID is only the last 32 bits of the fingerprint, and 32 bits is not enough to identify anything. Producing a different key with the same short ID takes minutes on ordinary hardware, and in 2019 the Evil 32 project did exactly that for every key in the PGP strong set and published the results, so a collision for a key you care about may already exist. The long key ID is 64 bits, which is better and still not a safe basis for trust. The full fingerprint is 160 bits for a version 4 key, and that is the value projects publish on their websites for a reason.

What is the `=XXXX` line at the bottom of the block?

A CRC-24 checksum of the binary data, defined in RFC 4880 as part of the armor format. It catches the ordinary accidents of copying a key around: a line dropped by a chat client, a wiki that reflowed the block, a paste that missed the last row. Base64 will happily decode a block that lost a line in the middle, and the packet parser may too, so without the checksum a mangled key can look plausible. This tool verifies it and tells you when it does not match. Note it is only an integrity check against accidents — it is not a signature and offers no protection against someone deliberately substituting a key.

Is it safe to paste a key here?

A public key, yes — it is meant to be published, and this page never sends it anywhere. All the parsing and the SHA-1 that produces the fingerprint run in your browser, which you can verify by loading the page, disconnecting from the network and pasting a key; it still works. A private key is another matter: never paste one into any web page, this one included. If the block begins with PRIVATE KEY the tool refuses to process it rather than quietly parsing it.

Why does the fingerprint use SHA-1 if SHA-1 is broken?

Because the version 4 key format defines it that way, and the fingerprint has to be computed identically everywhere or nobody could compare notes. SHA-1 is broken for collision resistance, which matters when an attacker controls both inputs — and for fingerprints that is a real concern, which is why the newer version 6 key format in RFC 9580 switched to SHA-256. This tool computes whichever the key's own version calls for, so a v4 key gets the SHA-1 fingerprint that gpg and every keyserver will show for it.

What is the difference between the primary key and a subkey?

The primary key is the identity: it carries the user IDs and certifies everything else. Subkeys hang off it and do the day-to-day work, typically one for signing and one for encryption, so the primary can be kept offline. That is why a key block usually shows several fingerprints, and why the one in an email signature may not be the one on the project's website — the signature was made by a subkey. Both are listed here, each with its own fingerprint, so you can tell which is which.

Can it check whether the key is revoked or who signed it?

No. It reads the packets and reports the keys, user IDs and dates it finds, but it does not verify signatures, follow certifications, or resolve the web of trust — all of which need other keys and, for revocation, a keyserver lookup. A key revoked yesterday still parses here exactly as it did the day before. For revocation status and signature verification you need gpg and a fresh fetch from a keyserver.

Related tools