SHA-256 hashes and UUIDv4 identifiers solve different problems

A hash describes input; a UUID names a record

SHA-256 deterministically maps the same byte sequence to the same 256-bit digest. UUIDv4 uses random or pseudorandom bits to create a 128-bit identifier with extremely low collision probability. One is content-derived; the other is intentionally independent of content.

Choose a hash when identical normalized input should produce an identical value. Choose a UUID when separate clients need to create record identifiers without asking a central counter for the next number.

Byte-for-byte details matter for hashing

Text must be encoded into bytes before hashing. UTF-8 is a sensible default, but line endings, trailing whitespace and Unicode normalization can still change the digest. Document the exact preprocessing rules when two systems must agree.

• Preserve or remove final newlines deliberately
• Agree on UTF-8
• Do not lowercase content unless the protocol requires it
• Compare lowercase and uppercase hex as representations of the same bytes

Neither value grants security by itself

A UUID is not an authorization token merely because it is difficult to guess. A plain SHA-256 digest is not suitable for password storage because attackers can test guesses quickly. Access control still needs authenticated permission checks, and passwords need a slow salted password-hashing function.

Choose the UUID version for the data model

UUIDv4 is appropriate for random identifiers and is what the XXF generator creates. RFC 9562 also defines UUIDv7, which includes Unix-epoch time for sortable identifiers. Do not silently change versions when downstream systems validate a specific layout.