A SHA-1 certificate hash is the 160-bit SHA-1 message digest of a certificate's exact byte sequence, displayed as 40 lowercase hexadecimal characters. Because the SHA-1 hash generator runs in your browser and hashes the raw bytes of a file without uploading it, you can point it at an exported certificate (.cer, .crt, .pem, .der) and read the same 40-character fingerprint that Android Studio, OpenSSL, or Java's keytool would print. The trick is to use file mode rather than text mode, since a certificate is binary data and pasting its contents into a UTF-8 text field would silently corrupt the bytes. Once the digest is computed, you compare every character through a trusted channel — a signed release page, a developer portal, or an out-of-band verification — to confirm the file you received matches the one the publisher intended.
What a SHA-1 Certificate Hash Actually Is
A digital certificate is just a chunk of binary data — usually a DER-encoded ASN.1 structure defined by X.509. Whether you save it as a .pem file with BEGIN/END markers or as a raw .der file, the bytes that are actually hashed are the certificate body itself. The SHA-1 fingerprint is therefore a deterministic function of those exact bytes: same bytes in, same 40-hex-character digest out. The fingerprint is widely used in development workflows (Android keystores, code-signing certificates, OAuth client secrets, TLS pinning scripts) where you need a stable, compact identifier for a specific certificate without exposing the public key in full.
SHA-1 is defined by the NIST Secure Hash Standard, which pads the input, splits it into 512-bit blocks and runs eighty rounds of mixing per block to produce a 160-bit state (see NIST FIPS 180-4). For an X.509 certificate the input is just whatever bytes sit inside the file you point the tool at — no header, no metadata, no modification timestamp, no MIME label. The 40-character hex string the generator returns holds the same SHA-1 digest bytes that tools like OpenSSL compute for the certificate, so it can be compared against the underlying fingerprint value used in existing verification scripts.
Hash a Certificate File With the SHA-1 Generator
- Open the SHA-1 hash generator in your browser. The page runs entirely in the tab and never uploads the file you select.
- Export the certificate you want to fingerprint as a file on disk. PEM and DER are both fine; the generator hashes raw bytes, so the on-disk extension does not matter. If the certificate lives inside a keystore (.p12 / .pfx / .jks), export the cert first using your platform's tooling — the SHA-1 of the keystore container is not the same as the SHA-1 of the certificate inside it.
- Switch the input mode to "file" rather than "text". A certificate is binary; pasting it into a UTF-8 text field would silently corrupt it and produce a meaningless fingerprint.
- Click the file picker and choose the certificate file. The 100 MB limit applies to the whole file, which is far above any realistic certificate size (most are well under 10 KB).
- Trigger the digest calculation. The page reads the bytes via the browser's File API, runs the standard FIPS 180-4 SHA-1 compression, and displays the result as 40 lowercase hex characters and 28 Base64 characters.
- Copy the hex string. Strip no whitespace, add no line breaks, and treat it as exact text. Most tooling expects lowercase.
- Compare every character against the value published by the certificate owner through a trusted channel. A match confirms you received the intended bytes; a mismatch means the file was modified in transit or you are looking at the wrong file.
Hex or Base64: Picking the Format the Certificate Tool Wants
The same 20-byte digest can be written two ways: 40 lowercase hexadecimal characters or 28 Base64 characters (27 data characters plus 1 padding character under standard RFC 4648). Android Studio's gradle signingReport, Facebook's Android key-hash field, and most OpenSSL command output all want the hex form. Some web APIs and older certificate pinning libraries accept only the Base64 form, and a few integrations accept either as long as the length is correct.
If the documentation is silent, default to hex — 40 lowercase characters, no spaces, no colons. If you are feeding the digest into a tool that already showed a sample with colons (a common convention in Windows certificate managers), strip them before comparing. The bytes are identical; only the printable encoding differs.
Common Pitfalls When Comparing Certificate Hashes
- Hashing the wrong file. The fingerprint of a keystore is not the fingerprint of the cert inside it. Hash the certificate you intend, not its container.
- Decoding PEM before hashing. Only the raw bytes matter. Stripping the BEGIN/END markers and Base64-decoding the PEM body gives a different file with a different digest. Either hash the .pem file whole or export to .der first.
- Comparing case-insensitively when one side is uppercase. Hex digits 0–9 and a–f are case-insensitive in value, but trailing whitespace, BOMs, and stray colons are not. Treat the printed fingerprint as exact text.
- Hashing a re-saved copy. If you open the certificate in a text editor and re-save it, line endings may have changed. The fingerprint will not match the original. Use the original file.
- Confusing SHA-1 with SHA-256. Google's Play Console, modern OAuth providers, and current Android signing reports now publish SHA-256 digests (64 hex chars). SHA-1 and SHA-256 fingerprints of the same certificate are completely unrelated values.
Why Legacy Systems Still Publish SHA-1 Certificate Digests
SHA-1 is collision-broken — attackers can construct different content with the same digest under realistic conditions, as documented in the security considerations of RFC 6194. A SHA-1 match is therefore not proof of authorship and must never be used for new signature schemes, password storage, certificate issuance decisions, or tamper protection. The SHA-1 fingerprint of a certificate is acceptable only because it acts as a compact identifier: you are confirming "this is the same file I downloaded before," not "this certificate was issued by someone trustworthy."
For new integrations, prefer SHA-256 or stronger. The SHA-256 hash generator computes the standard 256-bit digest of the same certificate file and returns the 64-character hex string that Google's Play App Signing, modern OAuth flows, and current TLS pinning tools expect. If you control the certificate publisher, publish the SHA-256 fingerprint alongside (or instead of) the SHA-1 one and migrate consumers over time.
SHA-1 vs SHA-256 vs SHA-512: A Quick Reference
| Property | SHA-1 | SHA-256 | SHA-512 |
|---|---|---|---|
| Digest size (bits) | 160 | 256 | 512 |
| Hex characters | 40 | 64 | 128 |
| Base64 characters | 28 (incl. =) | 44 (incl. =) | 88 (incl. ==) |
| Block size (bits) | 512 | 512 | 1024 |
| Rounds per block | 80 | 64 | 80 |
| Collision status | Broken | Secure | Secure |
| Standard | FIPS 180-4 | FIPS 180-4 | FIPS 180-4 |
The hex length is fixed by the algorithm — every implementation that claims to output SHA-1 must produce exactly 40 lowercase hex characters for the same input bytes, which is why a missing or extra character immediately tells you the file is wrong, the encoding is wrong, or the algorithm is wrong.
Limits and Edge Cases Worth Remembering
The browser-based generator accepts certificate files up to 100 MB; real X.509 certificates fit comfortably under 10 KB, so the limit is essentially transparent. It works only inside a single tab, processing the file in memory as one byte buffer before the digest operation completes — it is not a streaming command-line replacement for multi-gigabyte artifacts. For very large bundles, hash each certificate individually with this tool and verify each fingerprint against its published reference.
An empty input is a valid message and has the well-known SHA-1 value da39a3ee5e6b4b0d3255bfef95601890afd80709; clicking the calculate button with an empty text field still produces this constant. That is rarely what you want for a certificate, and a fingerprint that matches the empty-input constant almost always means the wrong file was loaded or the file picker never fired.
If you're weighing options, Generate a SHA-256 Hash in JavaScript: Web Crypto and Tool covers this in detail.