SHA-256 Hash Generator Guide: UTF-8, SHA-384 and SHA-512

How to generate a text hash

Open SHA-256 hash generator and paste text, open a local text file or leave the editor empty. Algorithm defaults to SHA-256; SHA-384 and SHA-512 are also available. Press Generate hash explicitly. Typing alone does not generate a digest, and changing the input or algorithm invalidates the previous result.

Read the selected algorithm with the result, then use Copy result or Download. Empty input is permitted and produces a real nonempty digest. Wrap lines changes visual wrapping only. Before comparing another application’s value, confirm that both sides hash the same byte sequence with the same algorithm and use comparable output representations.

• Keep trailing spaces and line endings deliberate; do not remove them merely to make a comparison pass.
• Use a fixed known example such as abc to check the selected algorithm before investigating a real payload.
• Retain the original data and the trusted expected digest separately from screenshots or shortened display values.

SHA-256, SHA-384 and SHA-512 output lengths

These are three members of the SHA-2 family. Their digest lengths are fixed regardless of whether the input is empty, a short word or a longer permitted text. A hexadecimal character represents four bits, so a 256-bit digest has 64 hexadecimal characters. Leading zero bytes remain represented; this tool does not shorten the output. The workspace’s byte badge counts the UTF-8 hexadecimal text: 64, 96 or 128 bytes, rather than the raw digest byte length listed below.

Choose the algorithm required by the receiving format or comparison process. SHA-384 uses its own initialization and is not simply a prefix of a normal SHA-512 digest. A SHA-512 result cannot be compared directly with a SHA-256 result as if the extra characters were optional. Longer output alone does not make a password-storage scheme or establish that your surrounding application is secure. This interface does not offer SHA-1, MD5, SHA-3, HMAC or a salt/key setting.

NIST FIPS 180-4: Secure Hash StandardW3C Web Cryptography API: Digest and SHA algorithms

Known SHA-256 examples: empty text and abc

The table gives complete lowercase SHA-256 digests of exactly the stated UTF-8 input. The empty-string example has zero input bytes; it is not the digest of a space or a newline. The abc example has the three ASCII bytes 61 62 63 in hexadecimal. These are fixed test examples, not a measurement of your input.

Copy the full digest rather than a shortened preview. If a reference writes hexadecimal in uppercase, letter case in the representation is different from the underlying digest bytes; ToolMellow emits lowercase. A Base64 representation of the same digest bytes would be another encoding, not another hashing algorithm. This tool provides no output-format selector.

NIST FIPS 180-4: Secure Hash StandardWHATWG Encoding: UTF-8 and text decoding

UTF-8 bytes, spaces and Unicode normalization

Before hashing, the tool checks for unpaired Unicode surrogates, then converts the input string to UTF-8. It does not trim spaces, remove a leading U+FEFF already present in the supplied string or apply Unicode normalization. A trailing space, case change or different byte representation can change the digest. The hash operation uses the string supplied to the worker.

Two strings can look the same while differing in bytes. For example, precomposed U+00E9 and the sequence U+0065 U+0301 can display the same accented letter but have different UTF-8 encodings. Likewise, LF and CRLF are different byte sequences. Browser text editing or import can affect the supplied string, so do not infer byte identity from appearance alone.

WHATWG Encoding: UTF-8 and text decodingECMAScript: String isWellFormedWHATWG HTML: Textarea values and line endings

Opening a text file is not hashing its original bytes

The file control reads through File.text(), which decodes UTF-8 text, removes a leading UTF-8 BOM and replaces malformed UTF-8 sequences. A file must be smaller than 4,000,000 bytes, and its loaded text must fit the one-million UTF-16-unit input limit. A filename extension does not establish the character encoding.

The decoded string is then encoded to UTF-8 for the digest, so the result can differ from a checksum computed directly on the original file bytes. Binary documents, images, a BOM, another character encoding or replacement characters can matter. For byte-exact file verification, use a method that reads and hashes raw bytes with the expected algorithm; this workspace is not that file-checksum method.

W3C File API: Blob text readingWHATWG Encoding: UTF-8 and text decoding

What a matching or different hash tells you

For a useful comparison, establish the same algorithm, byte sequence and full digest representation on both sides. A mismatch means those computed digests differ; it does not identify whether the cause is editing, encoding, a wrong algorithm, transport damage or another change. Known vectors help separate basic operation from assumptions about the real input.

A matching unkeyed digest supports consistency with the expected value, but is not a signature, identity check or proof that content is harmless. Cryptographic hashes have a finite output space and are not mathematically unique identifiers for every possible message. Trust the expected digest’s source: if both content and reference value are replaced, matching them alone cannot establish authenticity.

NIST FIPS 180-4: Secure Hash StandardW3C Web Cryptography API: Digest and SHA algorithms

A hash cannot be decrypted, but guesses can be tested

Hashing produces a digest rather than ciphertext with a decryption key. ToolMellow has no decrypt or original-text recovery function. Encryption, Base64 encoding and hashing have different roles: Base64 reversibly represents bytes, while encryption needs a cryptographic scheme and keys. A digest is not a compressed version from which arbitrary input can be reconstructed.

That does not mean every hashed input is impossible to guess. Someone can hash candidate values and compare them, especially when the original is short or predictable. A published hash therefore is not a blanket secrecy guarantee. Adding a hashing step alone does not solve authentication, key management or secure storage.

NIST FIPS 180-4: Secure Hash StandardOWASP: Password Storage Cheat Sheet

Why plain SHA-256 is not a password-storage system

This tool runs an unkeyed SHA-2 digest without a password-specific work factor, salt management or account-verification procedure. Choosing SHA-384 or SHA-512 changes the digest but does not add those capabilities. Entering a salt-like string manually is also not equivalent to implementing a complete password-storage scheme.

Password storage needs a construction designed for that purpose and appropriate application controls. Follow current password-storage guidance for the system you are building. HMAC and digital signatures address keyed authentication with different constructions; ToolMellow’s text digest does not generate or verify either. Keep real credentials out of public examples and screenshots.

OWASP: Password Storage Cheat SheetW3C Web Cryptography API: Digest and SHA algorithms

Use result as input hashes hexadecimal text

After generating a digest, Use result as input puts its hexadecimal characters into the editor. Generating again hashes the UTF-8 bytes of that text. It does not automatically feed the raw 32, 48 or 64 digest bytes into another hash operation, and this interface does not provide a raw-byte input mode.

If a protocol requires a second hash of raw digest bytes, a text operation on the visible hexadecimal result is a different computation. Identify the required representation at every step instead of assuming “hash twice” defines one universal operation. Repeating an unkeyed digest here does not turn it into password storage or keyed authentication.

WHATWG Encoding: UTF-8 and text decodingW3C Web Cryptography API: Digest and SHA algorithms

Input limits, Web Crypto and HTTPS

The input ceiling is 1,000,000 JavaScript UTF-16 code units, not one million UTF-8 bytes or visible graphemes. Emoji and combining sequences illustrate why those counts differ. The selected SHA-2 digest output remains its fixed hexadecimal length, so a permitted result fits the input ceiling for reuse; practical browser memory and worker availability still matter.

The browser must expose crypto.subtle in an appropriate secure context, such as HTTPS or a trustworthy local context including localhost. If the API is unavailable, the tool displays its support error. HTTPS alone does not guarantee every browser or embedding environment supports the required API. A standardized algorithm is not evidence that this browser, website or implementation has FIPS validation or certification.

ECMAScript: String isWellFormedW3C Web Cryptography API: Digest and SHA algorithmsW3C Secure Contexts: Potentially trustworthy origins

Troubleshoot a failed or unexpected text hash

If generation fails, read the error, confirm a supported algorithm and secure-context Web Crypto availability, and inspect the input for unpaired surrogates. An import-limit error differs from a hashing error. Do not change text until you know which byte representation the expected result describes.

When a comparison fails, start with the known abc vector, then compare the real input conditions one at a time. The tool does not diagnose corruption, produce a verification certificate or fetch a reference checksum from a URL. If clipboard access is unavailable, select the digest and copy it manually.

W3C Web Cryptography API: Digest and SHA algorithmsWHATWG Encoding: UTF-8 and text decoding

Text downloads, clearing and local privacy

Download saves the hexadecimal result as UTF-8 text in toolmellow-result.txt, not as raw digest bytes, a binary checksum manifest or a report. Clear removes input, output, errors, search/replacement content and editor history while retaining Algorithm and Wrap lines. Refreshing or closing the workspace discards its in-memory work; downloaded files remain on your device.

The application does not upload the supplied text, selected file contents or result to a hashing server. Loading the site still sends ordinary metadata to hosting, and the public site uses Google Analytics for page visits with cookies and browser/device information. Local hashing does not imply anonymity, zero network traffic or zero infrastructure logging. Clear does not guarantee forensic erasure from browser or operating-system memory.

Embed the hash generator with its backlink

Choose the page language and open the integration section below the workspace. Copy or download its HTML snippet into a website area that permits external iframes and scripts. The snippet contains the ToolMellow workspace iframe, sizing script and a visible backlink to the matching localized ToolMellow page. Retain that credit link.

Check the preview on narrow screens, the embedded secure context and clipboard permissions. The embed keeps the same algorithms, text scope and input limits; it does not become a remote hashing API, file-checksum service or password-verification system. The supplied credit link uses nofollow and noopener, and does not guarantee a ranking improvement.

Common questions

Sources and further reading

• NIST FIPS 180-4: Secure Hash Standard
• W3C Web Cryptography API: Digest and SHA algorithms
• WHATWG Encoding: UTF-8 and text decoding
• W3C File API: Blob text reading
• ECMAScript: String isWellFormed
• WHATWG HTML: Textarea values and line endings
• W3C Secure Contexts: Potentially trustworthy origins
• OWASP: Password Storage Cheat Sheet