Hashes, IDs, and randomness
Does a matching CRC prove a file is safe?
Tools to use
An eight-digit hex value beside a file matches your result. That can feel like proof the file is safe, but CRC32 does not establish authorship or harmlessness. It is useful for investigating mismatches and corruption. First check the calculation variant with a short known input, then decide what the comparison actually establishes.
Check the CRC variant with 123456789
123456789
CRC-32/ISO-HDLC: cbf43926Enter only the nine characters 123456789, without the example's label or a trailing newline. The result is cbf43926 for CRC-32/ISO-HDLC. Another CRC32 variant may produce a different expected value for the same bytes, so the name alone is not enough to align parameters.
Eight hex digits represent 32 bits. Retaining leading zeros keeps comparisons unambiguous. Hex letter case does not change the value, but missing digits or a different variant are not merely case differences.
Compare bytes rather than visible text
A file containing 123456789 plus LF is different; CRLF differs again. Text input is encoded as UTF-8, while file selection uses its actual bytes. Encoding, BOM and trailing newlines can change a visually identical document. Check the source, length and byte conventions before blaming the algorithm.
Removing a newline to obtain a match does not prove the original file was correct. Byte-for-byte distribution checks differ from comparing textual meaning. For a published file checksum, compare the actual artifact bytes instead of normalizing until a value matches.
Different files can share one CRC
CRC32 has 2³² possible outputs but vastly more possible files, so collisions are unavoidable. It is not cryptographic authentication against deliberate modification. Matching values must not be presented as absolute proof of identical input or absence of malicious changes.
A mismatch establishes a difference if the same variant and target were used, but not its location, cause or which copy is correct. Check version differences, transformations and mistaken files. The checksum starts an investigation; it is not repair data.
Authenticity depends on where the reference came from
Even with SHA-256, the expected digest needs a trusted source. If an attacker replaces both file and reference, a match does not authenticate the publisher. Signed artifacts require verification with the appropriate key and procedure; CRC32 or a plain SHA calculation does not perform that verification.
Neither CRC32 nor SHA encrypts the file. Lacking a reverse-conversion button is not confidentiality. Do not repurpose CRC32 for password storage or authorization. Checksums, hashes and signatures have different roles even when their displayed values look similar.
Record the target and variant with the result
Record version, byte length, CRC variant, reference source and result, not just the filename. 'This artifact's CRC-32/ISO-HDLC matches the distribution record' is reproducible and narrower than 'safe'. Report the check you actually performed.