What a hash actually guarantees
A cryptographic hash function takes an input of any length and produces a fixed-length digest. SHA-256 always returns 256 bits whether you fed it a single word or an entire film. Three properties make that useful.
It is deterministic: the same input produces the same digest, on any machine, in any language, forever. It exhibits the avalanche effect: changing one bit of input changes roughly half the output bits, so two nearly identical files produce digests with no visible relationship to each other. And it is preimage resistant: given a digest, there is no practical way to work backwards to an input that produces it.
That last property is why hashing is not encryption. Encryption is built to be reversed by whoever holds the key. Hashing is built so that nobody can reverse it, including you. Hash something, lose the original, and it is simply gone.
Why hashing a password with SHA-256 is the wrong move
This catches a lot of otherwise careful developers. The properties above make SHA-256 excellent for integrity checking and unsuitable for storing passwords, for one reason: it is fast. Deliberately, enormously fast, because verifying a large file should not take all afternoon.
Speed is exactly what an attacker holding a leaked database wants. Commodity hardware computes billions of SHA-256 digests per second, so working through every plausible password is cheap. Worse, an unsalted digest of a common password is identical in every database in the world, which is what rainbow tables exploit: the work is done once and reused against everybody.
Password storage needs a function built to be slow and memory-hungry, with a per-user random salt so that identical passwords produce different digests. bcrypt, scrypt and Argon2 exist for this and have tunable cost factors that can be raised as hardware improves. A general-purpose hash generator, this one included, is the wrong tool for that job.
MD5 and SHA-1: broken, but not for everything
Both are considered broken, and it is worth being precise about what that means, because plenty of software still uses them legitimately.
What is broken is collision resistance: it has become practical to construct two different inputs that produce the same digest. In 2017 a research team published two distinct PDF files sharing one SHA-1 hash. That destroys their use in signatures and certificates, where an attacker able to build a collision can get one document signed and then substitute the other.
What is not broken is preimage resistance. Given a specific SHA-1 digest there is still no practical way to find an input matching it. That is why a checksum published by a project you already trust remains a perfectly good way to detect accidental corruption in a download: it guards against a truncated transfer or a failing disk, not against a determined adversary. For anything security-relevant, use SHA-256 or better.
Verifying a download in practice
This is the most common legitimate use of a hash generator, so the workflow is worth knowing. A project publishes the expected digest for a release alongside the file itself. You download it, compute the digest yourself, and compare the two.
The comparison should be exact and complete. Checking that the first and last few characters match is a habit worth breaking, since an attack of this kind is precisely one that preserves whichever parts a human is likely to glance at. Copy both values and let the machine compare them.
One practical wrinkle: digests are usually published as lowercase hexadecimal, but some projects publish Base64 instead, which is shorter and looks completely different. The same SHA-256 digest is 64 hex characters or 44 Base64 ones. If yours does not match, check you are comparing the same representation before concluding anything is actually wrong.