SHA-256 always produces a 64-character hexadecimal digest of exactly 32 bytes (256 bits) for whatever byte sequence it receives, so to generate a SHA 256 hash of a string you first have to decide exactly which bytes the string represents. The SHA256 Hash Generator runs the standard NIST FIPS 180-4 algorithm in your current browser tab and returns the same digest whether the input is a single character, a multi-line paragraph, or an empty string, with two output formats representing the identical 32 bytes. Text input is encoded as UTF-8 before hashing, which means an accented character, an emoji, or a character from a non-ASCII script counts as two, three, or four bytes instead of one, and the displayed byte total is included for that reason. Files are hashed byte for byte without any text decoding step. Nothing you enter or select leaves the browser, so you can safely compute checksums for credentials, API payloads, or proprietary strings.
What SHA-256 Actually Does to a String
Many people picture a hash as a transformation of "characters," but the algorithm only sees bytes. The SHA-256 function from the SHA-2 family specified by FIPS 180-4 pads the byte input, splits it into 512-bit blocks, expands each block into a 64-word schedule, and updates eight 32-bit working values until the final eight words are concatenated into a 256-bit digest. None of that work happens at the character level. For a string, the characters must first be turned into bytes by an encoding, and the only standard choice is UTF-8.
The implication is concrete. The string café written with the precomposed "é" character is five bytes in UTF-8 (c, a, f, plus two for é). The same logical word written with a combining acute accent (e + ́) is six bytes (c, a, f, e, plus two for the combining mark) but the two byte sequences are different, so the two SHA-256 hashes are different even though both look like "café" on screen. This is why the tool shows a byte count alongside the digest — the byte count is part of the context that explains why two results agree or disagree.
Generate a SHA-256 Hash of a String
- Open the SHA256 Hash Generator in your browser and choose the text input mode.
- Paste or type the exact string you want to hash, paying attention to spaces, line breaks, and any trailing newline your source may have added.
- Read the byte count shown beneath the input to confirm the UTF-8 size matches what you expect — a mismatch usually means invisible characters or a different encoding.
- Generate the SHA-256 digest and copy either the 64-character lowercase Hex representation or the padded Base64 representation, depending on what the system you are comparing against expects.
- Compare the complete output character by character against an authenticated reference; if the comparison passes, the bytes match, and if it fails, the input bytes do not match even by a single space.
Why Two Strings That Look Identical Can Hash Differently
Hash mismatches with strings almost always come from a one-byte difference that the human eye cannot see. The most common culprits, in roughly the order they appear in real support tickets, are listed below.
- A trailing newline. Many command-line tools and editors add a final \n when saving text. echo "test" in a typical shell appends a newline that the browser textarea does not, producing a five-byte digest versus a four-byte one.
- Line-ending bytes. Windows files use CRLF (\r\n) and Unix files use LF (\n) only. The byte sequences are different, so the hashes are different. Copy-pasting between systems can silently convert one into the other.
- Unicode normalization forms. NFC and NFD represent the same visible characters with different byte sequences. A string from a Mac and a string from a Windows tool may normalize differently.
- Zero-width characters. Right-to-left marks, byte-order marks (BOM), and zero-width joiners look like nothing on screen but add bytes that change the digest.
- Encoding mismatch. A Latin-1 byte sequence interpreted as UTF-8 produces a different hash than the same characters typed directly as UTF-8.
The single safest diagnostic is the byte total the SHA256 Hash Generator displays next to the input. If the byte count matches the size you expected, you are hashing the right bytes; if not, the mismatch is in the encoding pipeline, not in the algorithm.
Hex and Base64 Outputs at a Glance
The 32 result bytes can be written in two equally valid ways. Both encode the same digest; only the presentation differs, and neither carries hidden information the other lacks.
| Property | Lowercase Hex | Standard Base64 |
|---|---|---|
| Length of the printable string | 64 characters | 44 characters with padding |
| Number of bytes encoded | 32 bytes | 32 bytes |
| Character set | 0–9 and a–f | A–Z, a–z, 0–9, +, / |
| Case sensitive | Yes — uppercase vs lowercase is presentation only | Not applicable |
| Where you typically see it | Software release pages, package managers, Git commits | JWT and JWS signatures, compact API tokens |
Changing the letter case of the hex output does not change the digest; the underlying 32 bytes are identical. Always copy the format the receiving system expects, and record the algorithm name ("SHA-256") alongside any digest you store so a future reader cannot mistake a 64-character value for an unrelated checksum format.
Practical Uses for a String SHA-256
String hashing is useful whenever you need a short, fixed-size fingerprint of variable text and want to verify identity without revealing the original content. A few examples:
- Cache keys. Many content systems hash the canonicalized URL or query string with SHA-256 to produce a deterministic cache identifier that survives small formatting changes in the source.
- Content fingerprints. Commit message digests, issue tracker IDs, and pull-request titles can be hashed to create stable references in build logs.
- ETag-style validators. A server can publish the SHA-256 of a configuration blob so clients can detect when the blob has changed without downloading it again.
- Quick integrity checks. Hashing the body of an API request or a small JSON payload before sending lets you log a compact checksum alongside the request for later auditing.
For specifications of the SHA-256 message schedule used by these systems, see RFC 6234, which restates FIPS 180-4 for the internet community and confirms the 64-hex-character output length.
Beyond Plain Hashing
A matching digest proves identical bytes; it does not prove who produced them. If your goal is message authentication — making sure a value came from a partner that shares a secret with you — SHA-256 is the wrong primitive. Use HMAC-SHA-256 instead, which mixes a shared secret into the hash and is the appropriate choice for API request verification.
If your goal is to store user passwords, SHA-256 alone is also the wrong tool. It is intentionally fast, which is great for integrity checks but also helps attackers guess passwords at high rates. Real account systems store a unique random salt per user combined with a slow, memory-hard function such as Argon2id, scrypt, or bcrypt; the slow cost is the point. The SHA256 Hash Generator deliberately exposes only the raw standard digest so the result can be checked against the FIPS 180-4 specification and against command-line utilities without ambiguity.
Quick Sanity Check With the Empty String
The empty input has a well-known standard digest, which makes it a perfect smoke test. Encoding an empty string produces zero UTF-8 bytes, and the SHA-256 of zero bytes is, by definition, the constant e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855. If you type nothing into the SHA256 Hash Generator and copy the hex output, you should see exactly that 64-character string. If you do, the tool is implementing the standard correctly; if you see anything different, something in the encoding or the algorithm is wrong before the comparison is even meaningful.
For a deeper look, see SHA-512 Password Hash With Salt: What the Output Means.
For a deeper look, see Convert to UTF-8 in Python: Strings, Files, and Failures.