SHA256 generator

A SHA256 generator hashes bytes, not characters

This is the single fact that explains almost every surprise people have with hashing, and almost no tool says it out loud. A hash function does not accept letters. It accepts a sequence of bytes, so before anything can be hashed your text has to be turned into bytes, and there is more than one way to do that. This page uses UTF-8, which is what almost every modern language, database and HTTP header assumes by default. Under UTF-8 a plain English letter costs one byte, an accented Latin letter costs two, most CJK characters cost three, and an emoji costs four. That is why the readout above your result counts three separate numbers rather than one: the UTF-16 code units JavaScript calls length, the Unicode code points a person would call characters, and the UTF-8 bytes that actually go into the arithmetic.

The consequence is that two strings can look identical on screen, character for character, and still produce completely different sums. The clearest example is an accented letter. Written as a single precomposed code point it is two bytes; written as a plain letter followed by a separate combining accent it is three. Your screen draws them the same way, your eyes cannot tell them apart, and no amount of staring at the two hashes will explain the difference. The byte count will, in about one second, which is the reason it sits above the result instead of in a help page.

The text box rewrites Windows line endings, so the file path exists

There is one thing a text box on a web page cannot do, and pretending otherwise would make this tool quietly wrong. When you paste text containing Windows line endings — a carriage return followed by a line feed, CRLF — into a <textarea>, the browser strips the carriage returns before your code ever sees the value. This is not a bug and not something a clever workaround defeats; it is the HTML specification’s raw value normalization, and every browser does it. So the hash you get from pasting the contents of a Windows text file is the hash of that file with every CRLF turned into a bare LF, which is a different sequence of bytes and therefore a different sum from the one your build script or your colleague computed on the file itself.

That is why this page has a file path that is a peer of the text box rather than an afterthought. A file handed in here is read off your own disk in slices and hashed byte for byte, carriage returns included, so the answer matches what sha256sum would print. The receipt counts the line endings it actually saw — so many CRLF, so many bare LF, so many lone carriage returns — which turns the warning from a claim into a number you can check. Hash the same content both ways and the difference stops being theoretical.

Five algorithms at once, and which one to reach for

Every input is run through SHA-256, SHA-1, SHA-384, SHA-512 and MD5 in a single pass, so there is no algorithm menu to set before you can see anything. SHA-256 is listed first and is the right default: it is what package registries, API signature schemes, container digests and virtually every current specification expect. SHA-384 and SHA-512 are the same design working in 64-bit words rather than 32-bit ones, and they are worth choosing when a standard asks for them rather than as a general upgrade — in a browser they are actually slower than SHA-256, because JavaScript has no 64-bit integers and each one has to be simulated with a pair of 32-bit values.

SHA-1 and MD5 are both here and both broken, and the distinction that matters is between reproducing a value and trusting one. Deliberate MD5 collisions have been practical since 2004 and a SHA-1 collision was demonstrated in 2017, so neither should be used to prove that a file or a message is authentic. But a great deal of ordinary work still requires producing those exact values: a Git object identifier is a SHA-1, an ETag is often an MD5, and a legacy database column or a cache key does not stop needing its old value because the algorithm aged. Each row on the receipt carries that limit next to the sum rather than in a footnote, because the limit is part of what the number means.

Hashing a string is a different job from verifying a download

If what you are holding is a download plus a value the publisher printed beside the button, you want the SHA256 checksum checker instead. Its whole design is the comparison rather than the digest: it accepts the published value in any of the shapes publishers actually use — bare hexadecimal, a SHA256SUMS row, the tagged BSD layout — and states its verdict in plain words, so you are never handed a second sixty-four-character string to inspect yourself. It also runs one algorithm and streams the bytes, which keeps it quick on a multi-gigabyte disc image where this page, driving five hash functions across every byte, would take roughly five times as long. Where only MD5 is offered, the MD5 corruption checker keeps that narrower meaning attached to its answer.

The reverse direction does not exist, whatever the search results suggest. A digest is not a cipher: a cipher preserves its input so a key can restore it, while a digest throws almost all of the input away and produces a fixed-length value regardless of what went in. Because the set of possible inputs dwarfs the set of possible outputs, endless unrelated strings land on the same value, and there is consequently no original to bring back. A page offering to “decrypt” your value is running a dictionary lookup against a table somebody built earlier from likely passwords; it answers when the original was guessable and is silent otherwise. The same fact is why a password should never be stored as a bare digest.

Nothing you paste leaves this tab

API keys, session tokens, passwords and unreleased copy get pasted into hash generators constantly, and hardly anyone stops to ask where those characters travel afterwards. From this page they travel nowhere. The arithmetic happens in a Web Worker inside this tab, your input is never appended to the address bar, never kept in local storage, and there is no route on this site that would accept it if it tried. None of that has to be taken on trust: open the network tab before you start typing, then watch it record nothing new while five sums appear. Learning to run that check is worth more than the check itself, because it works on every site that makes the same claim and very few of them are ever tested.

Two related tools sit close to this one for the moments when the hash is not the answer you needed. When a string will not produce the sum you expect and the byte count looks wrong, the invisible character finder will show the zero-width space or byte order mark that came along when you copied it out of a web page. When you are trying to work out how two versions of a longer document differ, the text comparison tool answers that directly instead of telling you only that the two hashes disagree. And if what you need is not a digest at all but a reversible encoding — for an email attachment, a data URI or a JSON payload — Base64 encoding and decoding is the thing you are looking for, and unlike a hash it does convert back.