I have read everywhere that base64 encoding of unique binary/hex values results in unique output. The following two string encode to virtually the same output.

{"alg":"SHA1","typ":"JWT","iat": "Sep  8 2018  8:51AM", "exp": "Sep  8 2018  9:11AM"}

gives output:



{"alg":"SHA1","typ":"JWT","iat": "Sep  8 2018  9:10AM", "exp": "Sep  8 2018  9:30AM"}

gives output:


The only the difference between the two is: ExQU0ifQ== and MwQU0ifQ== at the end of the output.

Only the times are different in the two strings; is that why the difference is so minute?

  • 1
    $\begingroup$ As this is Cryptography Stack Exchange what is this question's concrete / specific relation to cryptography? $\endgroup$
    – fkraiem
    Commented Sep 8, 2018 at 9:29

3 Answers 3


The whole purpose of base64 encoding is to take arbitary byte values and transform them into a limited subset of ASCII characters so that they can be "safely" sent (older transmission protocols could garble some byte values because e.g. some raw bytes had special meanings to those protocols; the only data that would be expected to not be changed was plain ASCII text.)

It does this by encoding three bytes (24 bits) into 4 characters (each of which has 64 values, so encodes 6 bits as $2^6 =64$) in a pretty simple fashion (some extra rules for incomplete groups). So every aligned identical three bytes in two messages get encoded into the same 4 characters every time. So changing 1 byte only will change at most 2 adjacent characters in the result, if you study the transformation this is obvious.

There is no expectation of more changes: it's just another representation of the same bits in the same order, and easily reversed on the receiving end.

In fact (IMO) in any sensible protocol your JSON-formatted data should be sent as is, as it's already all ASCII, and base64 encoding adds nothing but using more bandwidth. When encrypted it should be random-like binary data and could be sent in base64 format (and this is in fact customary: PEM and PGP send their messages base64 encoded, and very often binary mail-attachments as well.)

  • 1
    $\begingroup$ Nit: PEM requires base64, but is no longer used for data, only certs, CSRs, keys, etc. PGP and S/MIME support base64, as do other non-crypto kinds of MIME (e.g. your 'attachments'), and HTTP which is partly based on MIME, plus quite a few other things. $\endgroup$ Commented Sep 9, 2018 at 3:13

Since only the times are different in the two strings is that why the difference is so minute?

Base64 has no intention to be cryptographically secure so it is perfectly acceptable if minor changes in the input result in minor changes in the output. In this particular case you get the difference in the following substrings

ExQU0ifQ== vs MwQU0ifQ==



which is a grand total of 5 differing characters which is the lower bound of what is to be expected given that 5 bytes of the input have changed. You may also want to note that Base64 essentially takes 3 bytes at a time and encodes them as 4 Base64 characters independently of all the other bytes, so there's no propagation to be expected.


As other answers have explained, all you have done with the base64 stuff is to change the language of the text. The two original texts vary only slightly, so the translated texts only vary slightly too.

The magic occurs when you encrypt. Any serious encryption will produce not only random looking ciphertext, but every binary bit of the ciphertext will change with a 50% probability if even one bit of the plaintext changes. To illustrate, I've encrypted your two strings with AES128 in CBC mode with key "ABCDEFGHIJKLMNOP". You get:-

String 1, IV "1111111111111111":


String 2, IV "2222222222222222":


Totally different, even though the input texts are quite similar. The IV and CBC business relates to modes of operation of a cipher primitive, and it's what you'll have to deal with in order to create a practical encryption. There's a tag that can also help.


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.