SHA-256 Hash Generator

Computes SHA-256, SHA-1, and SHA-512 digests of your text using the Web Crypto API - the browser's built-in, audited hash implementation, not a JavaScript re-implementation. Input is UTF-8 encoded before hashing, so the digests match what sha256sum produces for the same bytes on any platform. Because hashing runs locally, this is safe for text you would never paste into an online tool: the input never leaves your machine.

How to hash text with this tool

1. Paste or type your text into the Text in box. Every character counts, including spaces at the end and line breaks, because the input is not trimmed.
2. Press Hash. The Digests out box shows three labeled lines: SHA-256, SHA-1, and SHA-512, each as lowercase hexadecimal.
3. To compare against a published checksum, copy just the hex string from the line you need. Copy result copies all three lines with their labels.
4. Change a single character and press Hash again to see how completely the output changes.

An empty box produces no output at all, so you cannot hash the empty string here. For reference, its SHA-256 digest is e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.

What a hash is good for, and what it is not

A cryptographic hash turns input of any length into a fixed-size fingerprint. SHA-256 produces 256 bits (64 hex characters), SHA-1 produces 160 bits (40 characters), and SHA-512 produces 512 bits (128 characters). The same input always gives the same digest, a one-bit change scrambles about half the output bits, and there is no known practical way to find an input that matches a given SHA-256 digest or to find two inputs that share one.

That makes SHA-256 the right tool for:

• Integrity checks. Confirming that a string, config value, or downloaded file matches what the publisher hashed.
• Fingerprints and cache keys. Turning long content into a short, stable identifier, as git and many build systems do.
• Change detection. Storing a digest and recomputing it later to see whether anything moved.

It is the wrong tool for several jobs people often reach for it to do:

• Storing passwords. SHA-256 is designed to be fast, which helps attackers test billions of guesses. Use a slow, salted password hash such as Argon2id, scrypt, bcrypt, or PBKDF2.
• Encryption. A digest cannot be turned back into the input. If you need to recover the data, you need encryption, not hashing.
• Signing API requests with a secret. Hashing secret + message with SHA-256 or SHA-512 is open to length-extension attacks. Use HMAC-SHA256, which exists for exactly this purpose.

A worked example

Type hello with no line break and press Hash. The output is:

SHA-256  2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

SHA-1    aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d

SHA-512  9b71d224bd62f3785d96d46ad3ea3d73319bfbc2890caadae2dff72519673ca72323c3d99ba5c11d7c7acc6e14b8c5da0c4663475c2e5c3adef46f73bcdec043

Now press Enter after hello so the box contains a trailing line break. The SHA-256 line becomes 5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03. Capitalize the first letter instead and it becomes 185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969. Nothing in the digests hints that the inputs were nearly identical.

The same pair shows up in a terminal. printf 'hello' | sha256sum prints the first digest, while echo hello | sha256sum prints the second, because echo appends a newline.

Common problems and fixes

Your digest does not match one from a command line

The usual cause is a single invisible character: a newline added by echo, a trailing newline at the end of a saved file, or a space you copied along with the text. Hash with printf instead of echo, and check for trailing whitespace in the box.

Multi-line text matches on Linux but not on Windows

A browser text box always stores line breaks as a single line feed, so this tool hashes LF endings. A file saved on Windows usually has CRLF endings, which are different bytes and give a different digest. Convert the file to LF, or compare against a hash computed from LF text.

Accented text hashes differently from the "same" text

The letter é can be stored as one code point (U+00E9) or as e followed by a combining accent (U+0301). They look identical but encode to different UTF-8 bytes. café typed each way gives 850f7dc4... and 81ef060b.... Normalize both sides to the same Unicode form before comparing.

You need the hash of a file, not text

This page hashes text you paste, and binary files cannot be pasted faithfully. Use sha256sum file on Linux, shasum -a 256 file on macOS, or Get-FileHash file -Algorithm SHA256 in PowerShell. PowerShell prints uppercase hex. Case does not matter when comparing hex digests, so compare them case-insensitively.

Related tasks

When two inputs should hash the same but do not, the text diff checker can reveal the stray character. To inspect encoded tokens rather than hash them, use the Base64 encoder and decoder.

Questions this tool gets asked

Do these hashes match sha256sum on Linux?

Yes, for the same bytes. The text is UTF-8 encoded before hashing, which is what shell tools see when hashing a UTF-8 file. Note that a trailing newline in a file changes the hash; this tool hashes exactly what you type.

Why no MD5?

The Web Crypto API deliberately excludes MD5 because it is cryptographically broken. Shipping a JavaScript MD5 here would mean recommending a hash no one should use for anything security-relevant.

Is SHA-1 not broken too?

For collision resistance, yes, and it should not be used for signatures or certificates. It remains in the tool because legacy systems (git object names, some checksums) still need it for interoperability.

Related tools

• cron explainCrontab syntax explained, with the next five real run times.
• regex testPattern on line 1, text below - every match and group listed.
• uuid v4Cryptographically random UUID v4s, one or a thousand at a time.
• password genCrypto-random passwords with the entropy math shown.