Introduction

The phrase "string to unique integer hashing" mixes two different goals that are often incompatible. A hash function maps many possible strings into a fixed-size integer space, which means collisions are unavoidable if the input space is larger than the output space. So if you truly need uniqueness for arbitrary strings, a normal fixed-width hash is not enough.

First: Hashing Does Not Guarantee Uniqueness

This is the most important point. A 32-bit or 64-bit integer has a finite number of possible values. The set of all possible strings is effectively unbounded. By the pigeonhole principle, some distinct strings must share the same integer if you compress them into a fixed-size hash value.

So you must choose one of these goals:

• fast hashing with possible collisions
• guaranteed unique IDs through a lookup table
• reversible encoding with potentially very large integers

Option 1: Use a Hash and Accept Collisions

If you only need a stable integer fingerprint for indexing or bucketing, use a hash.

1import zlib
2
3value = zlib.crc32(b"example-string")
4print(value)

This is deterministic and fast. It is not collision-free.

For many hash-table or partitioning tasks, that is perfectly fine.

Option 2: Guarantee Uniqueness With a Map

If you need each distinct string to receive a unique integer inside your application, maintain a dictionary from string to ID and assign numbers as new strings appear.

1class StringIdMap:
2    def __init__(self):
3        self.lookup = {}
4        self.next_id = 1
5
6    def get_id(self, text):
7        if text not in self.lookup:
8            self.lookup[text] = self.next_id
9            self.next_id += 1
10        return self.lookup[text]
11
12
13m = StringIdMap()
14print(m.get_id("alice"))
15print(m.get_id("bob"))
16print(m.get_id("alice"))

This guarantees uniqueness within that mapping system because you store the assignments explicitly.

Option 3: Encode the String Reversibly

If the alphabet is constrained, you can encode the string as a large integer rather than hash it. For example, base-256 interpretation of UTF-8 bytes is reversible.

1def string_to_bigint(text: str) -> int:
2    return int.from_bytes(text.encode("utf-8"), byteorder="big")
3
4
5def bigint_to_string(value: int) -> str:
6    length = (value.bit_length() + 7) // 8
7    return value.to_bytes(length, byteorder="big").decode("utf-8")
8
9
10n = string_to_bigint("hi")
11print(n)
12print(bigint_to_string(n))

This preserves uniqueness and reversibility, but the resulting integer can be arbitrarily large, so it is not a conventional fixed-size hash.

What to Use in Practice

If you are building:

• a hash table: use a normal hash
• a database key for seen strings: use an explicit ID map
• a reversible codec: use encoding, not hashing

Choosing the right tool matters more than inventing a custom string-to-int trick.

Cryptographic Hashes Are Not Unique Either

SHA-256 and similar algorithms drastically reduce collision probability, but they still do not mathematically guarantee uniqueness over arbitrary inputs. They are excellent for integrity and fingerprints, not magical unique-ID generators.

Common Pitfalls

A common mistake is asking for a unique hash into a small fixed-size integer. That requirement is impossible for arbitrary strings.

Another mistake is using a hash when the real need is a stable application-level ID. In that case a lookup table is the correct design.

Developers also sometimes choose reversibility accidentally by converting bytes to a big integer, then assume they invented a hash. That is an encoding, not a hash.

Summary

• Fixed-size hashes cannot guarantee uniqueness for arbitrary strings.
• Use hashing when collisions are acceptable.
• Use a string-to-ID map when you need guaranteed uniqueness in an application.
• Use reversible integer encoding if you need to recover the original string.
• Pick the method based on the real requirement, not the overloaded word "hashing".