Is SHA-256 encryption?

No. SHA-256 is a one-way hash with no key and no supported reverse operation. It produces a fixed-size digest from which the original input cannot be recovered, which is fundamentally different from encryption.

Why does my Java result differ from a website or command-line tool?

The most common causes are a hidden added newline, a non-UTF-8 platform default charset, different Unicode normalization forms, or a mismatch between pasted text and file bytes. Specify StandardCharsets.UTF_8 explicitly and hash the file directly when verifying a download checksum.

Should I store passwords with SHA-256?

No. SHA-256 is far too fast and gives attackers too much throughput for guessing. Use a unique per-user salt and a memory-hard password hashing function such as Argon2id, scrypt, or bcrypt instead.

What is the difference between Hex and Base64 output?

Both encode the same 32 bytes. Hex produces 64 lowercase characters (0–9, a–f) and is the canonical form for published checksums. Padded Base64 produces 44 characters using the RFC 4648 alphabet and is convenient when the digest travels inside JSON or other text protocols.

Does a matching SHA-256 prove the file is authentic?

No. A matching digest only proves the bytes are identical to the reference. The reference digest itself must be obtained over an authenticated channel such as HTTPS from the owner or a signed release, otherwise an attacker can replace both the file and the displayed checksum.

Generate a SHA-256 Hash in Java: Code and Browser Method

Q: Can SHA-256 hash an empty string?

Yes. Empty input is a valid byte sequence with the standard well-known digest beginning e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855. Use it as a first correctness check on any new SHA-256 implementation.

A SHA-256 hash in Java is produced by feeding UTF-8 bytes through java.security.MessageDigest configured with the standard algorithm name "SHA-256", then formatting the resulting 32-byte digest as either 64 lowercase hexadecimal characters or standard padded Base64. The same input bytes always produce the same digest, but the digest cannot be reversed to recover the original message. SHA-256 belongs to the SHA-2 family specified in NIST FIPS 180-4 and is widely used for file integrity checks, build verification, and digital signature pre-images. Java's platform implementation delegates the underlying block scheduling and compression to the same FIPS 180-4 routine that browsers expose through Web Cryptography, so a hash produced by MessageDigest will byte-for-byte match the digest returned by a browser-based generator when both sides operate on identical UTF-8 bytes. For one-off verification tasks, comparing your Java output against a published checksum, debugging a mismatch, or generating a digest for a non-programmer to validate, a browser SHA-256 Hash Generator returns the exact 64-character Hex value you can paste into a message or build manifest.

What a SHA-256 Digest Looks Like

SHA-256 always returns exactly 256 bits of output, which is 32 bytes regardless of input length. Java exposes those 32 bytes from MessageDigest.digest() as a byte array. To make the digest human-readable, the same 32 bytes are rendered in two standard encodings:

Representation	Length	Purpose
Lowercase Hex	64 characters	Each byte becomes two hex digits (0–9, a–f); the canonical form for published checksums and download pages.
Padded Base64	44 characters	RFC 4648 alphabet with trailing = padding; useful when the digest rides inside JSON, JWT, or other text-based protocols.
Raw bytes	32 bytes	What Java returns directly; required for HMAC, RSA signatures, and any cryptographic operation that consumes a digest.

Changing the letter case of the Hex form, for example uppercase A–F instead of lowercase a–f, only changes presentation. The underlying 32 bytes are identical, and a verifier that lowercases its input before comparing will still see a match.

The standard also defines a digest for empty input. The empty byte string hashes to e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855, which is the most cited SHA-256 test fixture and a reliable first check that any implementation is wired to the correct algorithm.

Generating SHA-256 in Java with MessageDigest

Java ships a FIPS-compliant SHA-256 implementation through java.security.MessageDigest. The standard pattern is to request the algorithm by name, feed it the exact bytes you want hashed, and then encode the resulting byte array as Hex or Base64 for display or transmission.

The full procedure has four short steps. First, obtain a MessageDigest instance with MessageDigest.getInstance("SHA-256"); the string literal must be exact, and the call throws NoSuchAlgorithmException only on a non-conforming JVM. Second, convert your input to bytes, always passing StandardCharsets.UTF_8 because the no-argument getBytes() falls back to the platform default charset and silently changes the digest whenever non-ASCII characters appear. Third, call digest(bytes) to receive the 32-byte array, or call update(bytes) followed by digest() if you want to feed data in chunks, which is the standard approach for files larger than available heap. Fourth, hex-encode the byte array, either by hand using a two-character String.format("%02x", b) loop or by delegating to HexFormat.of() in Java 17 and later.

For files, the typical pattern wraps a FileInputStream (or a NIO SeekableByteChannel) in a DigestInputStream, which streams bytes through the digest without loading the whole file into memory. That streaming behaviour matters once a file approaches the size limit of any browser-based alternative, because the SHA-256 Hash Generator passes the full byte buffer to the Web Cryptography digest interface rather than streaming it.

Computing the Same Digest in a Browser

A browser SHA-256 Hash Generator is useful when you want a quick, dependency-free check, when a teammate who does not write Java needs to verify a published checksum, or when you simply want a second opinion on the value your code just produced. The tool performs the exact FIPS 180-4 routine in your current tab and never uploads the bytes you select. Use it like this:

Open the SHA256 Hash Generator in a browser tab; no install, account, or network call is required for the actual hashing.
Choose text or file mode. In text mode, paste or type the exact string whose Java digest you want to reproduce, keeping in mind that spaces, line breaks, and trailing newlines are all bytes. In file mode, select the local file whose Java hash you want to cross-check; the tool reads the file bytes directly from disk without re-encoding.
Trigger the digest calculation. The tool passes the exact UTF-8 bytes (text mode) or exact file bytes (file mode) to the Web Cryptography SHA-256 implementation and displays the resulting 32 bytes in two forms: 64 lowercase Hex characters and standard padded Base64.
Copy the Hex representation if the other system expects a hex checksum, or copy the Base64 form if it expects that. Paste the value into your Java test, build manifest, or message and compare the complete string, not a prefix.
Record the algorithm name alongside any stored digest so a 64-character SHA-256 value cannot later be confused with another format, undocumented checksum, or a truncated digest.

Because both the Java MessageDigest path and the browser tool ultimately call the same FIPS 180-4 routine, the resulting digests are byte-for-byte identical for any given input. The Java implementation typically uses native code from the JDK provider, while the browser uses Web Crypto, but both implement the same padding, block splitting, and 64-word schedule described in NIST FIPS 180-4.

Comparing the Two Outputs Without Mismatch

A mismatched digest is almost always caused by the input bytes differing, not by a broken implementation. The table below lists the most common culprits and how to check each one. Use a password hashing workflow for password-shaped inputs, since the points below assume an integrity-checking use case.

Cause of mismatch	How to detect it	How to fix it
Platform default charset	Non-ASCII text produces different bytes on different machines.	Always pass StandardCharsets.UTF_8 explicitly.
Trailing newline	Command-line utilities append "\n" automatically.	Strip the final byte or hash a file instead of pasted text.
Line-ending style	Windows CRLF produces 0d 0a; Unix LF produces only 0a.	Normalize before hashing or hash the file as-is to match the publisher.
Unicode normalization	Accented letters or emoji have NFC and NFD forms that encode to different UTF-8 byte sequences.	Normalize explicitly with Normalizer.normalize(input, Form.NFC) or pick one canonical form upstream.
Text vs file bytes	Pasted text round-trips through decoding; file mode bypasses it.	Hash the file directly when verifying a download checksum.

Even after the bytes match, the reference digest must itself be authentic. If an attacker can replace both the file and the checksum displayed beside it, recomputing SHA-256 will confirm the attacker's pair. Obtain reference hashes over HTTPS from the owner, through a signed release artifact, or through another authenticated channel appropriate to the risk; the digest is integrity-only, not a guarantee of provenance.

When SHA-256 Is the Wrong Tool

SHA-256 is an integrity primitive, not an authentication primitive. Three common tasks are easy to confuse with integrity checks and will fail silently if you reach for raw SHA-256:

Password storage. SHA-256 is far too fast for this. Its speed is valuable for checksum workflows and exactly the wrong property for password verification, where an attacker can test billions of guesses per second on commodity GPUs. Account systems should store a unique salt per user and run the password through a purpose-built memory-hard function such as Argon2id, scrypt, or bcrypt. See how to generate a password hash the easy way for a concrete workflow.
Message authentication between two parties. Raw SHA-256 does not prove who created a digest. When two systems share a secret and need to authenticate that a message came from each other, use HMAC-SHA-256, which combines the secret with the message inside the hash.
Verifiable origin from a single public key. When a verifier needs to confirm that a specific party signed a message, use a digital signature such as RSA-PSS or ECDSA over the SHA-256 digest, not the digest on its own.

If your goal is only to confirm that two files match, or to reproduce a vendor's published checksum, raw SHA-256 is the correct choice and the SHA-256 Hash Generator will produce exactly the value you need.

Limits and Operational Notes

Three operational limits come up repeatedly when generating SHA-256 hashes in Java and verifying them elsewhere:

Input cap for browser tools. The SHA-256 Hash Generator accepts up to 100 MB of file bytes because the underlying Web Cryptography digest interface receives the full byte buffer rather than streaming it. Larger files should be hashed with a trusted streaming tool on the local machine, such as sha256sum on Unix or certutil on Windows, or with Java's DigestInputStream.
Empty input is valid. Hashing the empty byte string returns the standard digest beginning e3b0c442. The generator accepts empty text on purpose; if you instead see a non-empty digest, the input likely contains invisible characters such as a final newline or a zero-width space.
Authentication tests are separate. The NIST Cryptographic Algorithm Validation Program for Secure Hashing tests implementations against published answer sets, but the validation status of a particular library does not authenticate the bytes you hashed, only the algorithm's correctness.

For Java specifically, two further points save hours of debugging. First, the algorithm string passed to MessageDigest.getInstance is case-insensitive in modern JDKs but the canonical form is "SHA-256", and variants such as "SHA-256/224" or "SHA3-256" produce different digests. Second, when comparing digests across languages, hash the empty string on each side first; if both return the e3b0c442 fixture, the encoding, algorithm, and output format are all wired correctly and any remaining mismatch is in the input bytes.