Never use unsalted hashes for password storage
Storing SHA-256(password) in a database is insecure because attackers can precompute rainbow tables — lists of hashes for millions of common passwords. Always use a dedicated password hashing function: bcrypt, Argon2, or scrypt. These functions are intentionally slow (to resist brute force) and include a random salt (to prevent rainbow tables). The hash generator is useful for many things — password storage is not one of them.
Use SHA-256 checksums in your deployment pipeline
When deploying configuration files, build artefacts, or dependencies, generate a SHA-256 hash of each critical file before deployment. Store the hashes. After deployment, regenerate the hashes and compare — any difference indicates a file was changed unexpectedly. This is the foundation of supply chain security.
Compare file versions without opening them
If you have two copies of a large file and need to know whether they are identical, hash both with SHA-256. If the hashes match, the files are byte-for-byte identical. Much faster than a line-by-line diff for binary files.
Generate consistent identifiers from content
Hashing the content of a resource (image, document, data record) gives you a deterministic identifier that changes only when the content changes. This is used in HTTP caching (ETags), content-addressable storage, and deduplication systems. SHA-256 truncated to 8–16 characters gives a compact, collision-resistant ID.
Use the uppercase toggle for compatibility
Some systems expect uppercase hash strings (A-F rather than a-f), others expect lowercase. The uppercase toggle switches between the two instantly, avoiding the need to manually convert or use string manipulation in code.