Hashing and encoding in Python

A str is a sequence of characters and a bytes object is a sequence of raw byte values, so len answers a different question for each. The word has four characters, but the accented e is two bytes in UTF-8, so the encoded form is five bytes long. For plain ASCII text the two figures happen to agree, which is exactly why the difference is easy to miss. No newline is added, and the growth depends on the characters rather than on a fixed rule.

hashlib.sha256 wants a bytes object, and "hello" is a str, so Python refuses and says that strings must be encoded before hashing. Calling .encode() on the string first, or writing it as a bytes literal with a b in front, fixes the type, and the digest is then the same either way because the bytes are identical. Length is not the problem, and no key is involved: SHA-256 takes its input in one piece.

Both forms spell the same bytes; only the alphabet differs. Standard base64 uses + and /, and both characters mean something in a URL or a query string, so a value that travels in a link can be mangled. The URL-safe variant uses - and _ instead, so three bytes of 255 become b____ rather than b////. Neither form encrypts anything, the length is the same, and both take bytes and return bytes.

Hex is two characters per byte, so a hash or a key can be written down, copied and compared without ambiguity. The bytes of Hi are 48 and 69, which are H and i in ASCII, and 4869 reads back with bytes.fromhex. It is not hiding anything: hex reverses in one call, unlike a hash. It is also longer than the raw bytes rather than shorter, and every bytes object has the same .hex() method, not only hashes.