How IP hashing works, step by step
A visitor's IP address arrives with every request. Instead of storing that address in a database, an IP hashing system runs it through a one way cryptographic function, such as SHA-256, which converts it into a fixed length string of letters and numbers. The original IP address is not recoverable from the hash by reversing the math directly. The system then stores the hash and uses it the same way it would have used the raw IP: to recognize when the same visitor returns, without keeping the address itself on file.
Most serious implementations add a salt, a secret value mixed in before hashing, so the output is not just a hash of the IP but a hash of the IP plus a value only the operator knows. Salting is not decoration. It is the difference between a system that resists casual lookup and one that does not resist it at all, and the distinction matters more than most explainers of hashing let on.
Why hashing an IP address alone is not private
Here is the part most explainers skip. There are only about 4.3 billion possible IPv4 addresses. That is a small enough number that anyone with a modest amount of compute time can hash every one of them in advance and build a lookup table, called a rainbow table, that maps every possible hash straight back to its original IP address. An unsalted hash of an IP address is not anonymization. It is a lookup with extra steps, because the entire input space is small enough to brute force in hours, not centuries.
This is why regulators and privacy engineers treat a bare hash differently from a salted one. A random, kept secret salt breaks the precomputed rainbow table, because an attacker would need to know the salt before precomputing anything useful. It does not make the identifier meaningless, since the whole point is that it still recognizes the same visitor on a return visit, but it does make the raw IP address unrecoverable without the salt.
Salting approaches and what each one actually buys you
| Approach | How it works | Re-identification risk | Typical use |
|---|---|---|---|
| No salt | IP address hashed directly | High. Reversible via a precomputed IPv4 rainbow table | Should generally be avoided for anything touching personal data |
| Static salt | Same secret salt added to every IP before hashing | Low if the salt stays secret, but a single leak exposes every past and future hash | Common baseline for visitor recognition systems |
| Rotating or per period salt | Salt changes on a schedule, so hashes from different periods cannot be linked to each other | Lowest, and it limits tracking duration even if a salt leaks | Used when long term persistence needs to be deliberately limited |
Is a hashed IP address personal data under GDPR
Generally, yes. European data protection guidance treats hashing as pseudonymization, not anonymization. Pseudonymized data is still personal data under GDPR because the organization holding the salt, or capable of brute forcing an unsalted hash, can still link the identifier back to an individual, even if a third party looking at the hash alone cannot. Genuine anonymization, the kind that takes data outside GDPR's scope entirely, is a much higher bar than running a value through SHA-256 once. If a compliance case depends on "we hash it, so it is not personal data", that case is on shaky ground and worth revisiting with someone who reads GDPR guidance for a living.
What salting and hashing do buy, honestly, is a real reduction in exposure if a database leaks, and a real barrier against casual internal misuse, since nobody browsing the table sees a plain IP address. Those are legitimate security benefits. They are just not the same claim as "this data is anonymous."
IP hashing versus the alternatives
| Method | What's stored | Precision | GDPR posture |
|---|---|---|---|
| Plaintext IP storage | The raw IP address | Same as hashed, precision comes from the IP itself, not the storage format | Clearly personal data, no ambiguity |
| Salted IP hash | A one way hash of IP plus secret salt | Household or network level, roughly, and only a fraction of visitors resolve at all | Pseudonymized personal data, still in scope |
| Device fingerprinting | A composite signature built from browser, screen, fonts, and other device signals | Often finer than IP alone, and harder for a visitor to reset than an IP address | Personal data, treated with particular scrutiny by regulators because it resists opt out |
Where Raydar uses IP hashing
Raydar's visitor identification is IP hash based. It is not device fingerprinting and it does not pull from a data broker. Matches come back with an explicit high confidence or low confidence label rather than a flat yes or no, which reflects the reality that IP based signals vary in reliability depending on the network the visitor is on. This sits alongside standard click tracking and first party cookie data on every link, so a click's UTM source and referrer stay available even for the visitors who never resolve to an identity. For the mechanics of why a published match number needs a denominator to mean anything, see what a match rate actually measures, and for how this compares to fully cookieless approaches, see cookieless visitor identification.
What to check if a vendor says "we hash your data"
- Ask whether the hash is salted, and whether the salt rotates.
- Ask where the salt is stored and who can access it.
- Do not accept "it's hashed" as a substitute for a real answer on data retention or deletion.
- Remember that a hash generally still counts as personal data under GDPR, so consent and lawful basis questions do not disappear just because the field is a hash instead of an IP.