Is it possible that a single string produces two different hash results after going through the same SHA-256 hash function? The code I'm working on right now is doing this, and I assumed this should not be possible. Any help?

  • $\begingroup$ Most likely it's an uninitialized variable, or out-of-bound assignment. If you need help, there's loads of SHA256 implementations on the Internet you can reference. A good reference implementation can be found at IETF website RFC 6234. $\endgroup$
    – DannyNiu
    Commented Dec 26, 2017 at 4:07
  • $\begingroup$ You may want to note that the property that "if I put in the same thing twice I get the same result both times", is called determinism. $\endgroup$
    – SEJPM
    Commented Dec 26, 2017 at 11:17
  • 2
    $\begingroup$ Any help? – Yes, your implementation is faulty. Check your sourcecode and correct your errors accordingly. $\endgroup$
    – e-sushi
    Commented Dec 26, 2017 at 11:50
  • $\begingroup$ In which language you are writing the code? try analyzing the length of both the strings and also try comparing both strings char by char or xor both strings and see where it has 1's. you may find the difference. $\endgroup$
    – crypt
    Commented Dec 27, 2017 at 21:31

3 Answers 3


No. This doesn't make sense. SHA-256 is a mathematical function on bit strings. As such, it doesn't give different answers at different times of day or under different phases of the moon. It gives different answers only for different inputs.

  • 8
    $\begingroup$ My guess would be that the "single string" is actually two different encodings of the same string -- maybe one is in base64 or hex encoding vs. raw, maybe UTF-8 vs. some other character encoding, maybe one has a newline at the end... but something is different or the hashes would be the same. $\endgroup$ Commented Dec 26, 2017 at 2:03

Is this possible using the same message? No. But the message / input for SHA-256 is defined as a bit string, which - for most implementations - means an octet string, also known as a byte array. Of course, in practice, this usually means that the function has one or more update methods that accept bytes, and a method that finalizes the input, so that the whole message doesn't need to be available at once. As for most modern cryptographic algorithms, the input is binary, not text.

However, what you are likely are talking about is a string of text. Now textual strings are strings of characters. To map characters to bytes the text needs to be encoded using a character-encoding. An example encoding is US-ASCII or the - largely compatible - UTF-8. However, there are also others, for instance .NET uses UTF-16 as default encoding (usually UTF-16LE, to be precise, mistakenly called Unicode in .NET). Java uses different character encodings as default depending on the platform that you are on.

Besides character encoding, there may also be other tiny differences. In bash, it is often forgotten that echo by default adds a newline, for instance. Windows, Linux and Apple all use different line endings. Unicode may have different representations for the same character w.r.t. diacritics, so you may need to normalize Unicode character strings. Unicode strings may also contain an (invisible) byte order mark at the start of the string. And of course there are the invisible special, non-printable characters that may be hiding in a string.

All those kind of tiny differences will create a different bit string, and different bit strings produce a hash where all the output bits are unrelated to each other. So if you want to find why a different hash is created, perform a binary compare of the input of the hash function. Or print out the input for the SHA-256 in hexadecimals or base 64 and look for it with your own eyes.


PHP 5+, two hash(sha256, $key)?

If you try this:

  1. \$key = \$String1.\$String2.\$String3.\$String4.\$NumFloat."1234"."456"."Test".\$StringA.\$StringB;

echo \$key;

  1. \$key = "\$String1\$String2\$String3\$String4\$NumFloat"."1234"."456"."Test".\$StringA.\$StringB;

echo \$key;

everything being string except for \$NumFloat being of type float (for instance float decimal 2)

You will get the same $key on the screen, but if you try hash(sha256,\$key) on each \$key you will get two different results.

If you send the hash result to somebody who is testing you result, you have to switch to number 2 format, if number 1 gives you an error. This is because of internal conversion with type float.

(I have had some surprise after the tranfer of text from my HTML doc file to this page - strange format...) I found it difficult to correct. To try to correct it I had to copy from source but the draft kept on being the same... for instance: "$key on the screen,but if you try hash(sha256,\$key)" keep being wrong

  • 1
    $\begingroup$ Playing with the string tricks doesn't count. We need to look at what is entering into the SHA256 as binary. Nice try, doesn't work. $\endgroup$
    – kelalaka
    Commented Nov 27, 2020 at 11:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.