SHA-256 Hash Generator

Use hashes to compare bytes, then establish trust

This tool calculates SHA-256, SHA-512, and legacy SHA-1 digests from UTF-8 text using the browser's Web Crypto API. It requires a secure browser context such as HTTPS. The input is text, not a file picker: entering an APK filename hashes the filename, not the APK. Use local file tools for download checksums and Android build tools for signing verification. Keep private keys and credentials out of browser debugging workflows.

Collision resistance and the birthday bound

A hash maps arbitrarily long input into a fixed-size result, so collisions must exist. Collision resistance means it should be computationally impractical to find two different messages with the same digest. Preimage resistance is a different task: given one digest, find a message that produces it. Neither property means that a digest encrypts a message or proves who wrote it.

For an ideal n-bit hash, a generic collision search costs roughly 2^(n/2) operations, while a generic preimage search costs roughly 2^n. The approximate collision probability among k independent random digests is k(k - 1) / 2^(n + 1) when that probability is small. SHA-256 has 256 output bits and targets about 128-bit generic collision resistance; SHA-512 has 512 output bits and targets about 256-bit generic collision resistance.

These are idealized work estimates, not a claim that every algorithm meets them. SHA-1 has demonstrated collision weaknesses and should not be selected for new integrity or signature designs. Its output remains useful for compatibility with services that specifically request an existing certificate's SHA-1 identifier. A SHA-1 fingerprint requirement does not justify choosing SHA-1 for a new security protocol.

Reproduce a digest without accidental byte changes

SHA-256 outputs 32 bytes, normally displayed as 64 hexadecimal characters. Uppercase and lowercase hex represent the same bytes. By contrast, a trailing newline, a space, or a different Unicode normalization changes the input. The string abc, without a newline, should produce the following SHA-256 test vector. Use it to distinguish an implementation problem from a mismatch in your real payload.

ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

When hashing JSON, formatting and object-member order can change the byte sequence even if the decoded values appear equivalent. Agree on a canonical representation before using hashes as content identifiers. Do not assume that running a formatter creates a cryptographic canonical form. Similarly, hashing Base64 text differs from decoding that text and hashing its underlying bytes.

Verify an APK file and its signing certificate

A download checksum identifies the entire APK file. A certificate fingerprint identifies the signing certificate. Updating application resources changes the file checksum even when the signing certificate remains the same. On Windows, calculate the file digest locally with PowerShell. Compare all hexadecimal digits with a checksum obtained through a trusted independent channel; a checksum published beside a compromised download may also be compromised.

Get-FileHash -LiteralPath .\app-release.apk -Algorithm SHA256
apksigner verify --verbose --print-certs app-release.apk

The apksigner command checks Android signing validity and prints signer certificate information. Inspect the verification result, not just the printed fingerprint. A valid signature shows that the artifact is signed consistently; you must still compare the signer with the publisher you intended to trust. It does not prove that the application is harmless or that it came from the expected store.

Inspect SHA-256 and SHA-1 fingerprints with keytool

To inspect a local release keystore, replace the example alias and path below. Let keytool prompt for its password, keeping that secret out of command history and screenshots. The verbose output includes SHA1 and SHA256 certificate fingerprints. Copy the field required by your integration rather than hashing the colon-separated fingerprint string again.

keytool -list -v -keystore release.jks -alias release
keytool -list -v -keystore debug.keystore -alias androiddebugkey

Use the actual debug keystore path for your workstation. Local debug builds and release builds normally have different certificates. With Play App Signing, the upload key can also differ from the app signing key used for distributed APKs. Check Play Console's app signing certificate for production registrations, including any key rotation relevant to supported Android versions. A mismatch can explain why sign-in works locally but fails after store installation.

Security boundaries

A plain hash does not authenticate a request because anyone can recompute it. Use a vetted HMAC or digital signature protocol when origin matters. Password storage needs a dedicated slow password hashing construction, not one pass of SHA-256. Keep signing keys in controlled local or managed signing environments and record certificate changes with your release process.

Technical references

Consult NIST hash guidance, apksigner documentation, and Android app signing.

Frequently asked questions

Published by AndroidRich. Technical content updated 4 October 2026. Report a correction.