How We Hash IPs (and Why "Anonymized" Usually Isn't)

PVTLNK Team

“We anonymize your IP address” is one of the most common privacy claims on the internet, and it’s also one of the least precisely defined. Depending on who’s saying it, “anonymized” can mean anything from “we deleted the last octet” to “we ran it through a real cryptographic hash” — and those two things offer wildly different levels of protection while sounding identical in a privacy policy.

We hash IP addresses with SHA-256. Here’s what that actually buys you, and where the honest limits are.

Truncation isn’t hashing

A lot of “anonymization” in practice means zeroing out the last part of an IP address — turning 203.0.113.47 into 203.0.113.0, for instance. This is easy to implement and does provide some coarsening of location precision. It is not anonymization in any strong sense: it’s reversible-adjacent, trivially reduces the search space for identifying a specific user on a small network, and doesn’t protect against correlation across multiple requests from the same address.

Hashing is a different operation entirely. Running an IP address through SHA-256 produces a fixed-length, effectively irreversible output — you cannot derive the original IP from the hash. What you can do is compare hashes: the same IP address will always produce the same hash, so we can tell “this is the third click from the same visitor” without ever knowing what that visitor’s actual address is.

Where hashing alone still isn’t enough

Here’s the part most companies leave out: a plain hash of a real-world value with a small, guessable space isn’t actually irreversible in practice. IPv4 addresses are a well-known, enumerable space — about 4.3 billion possible values. An attacker with access to the hash output could, in principle, precompute the hash of every possible IP address and build a reverse lookup table, defeating the “you can’t get the original back” property entirely. This is the same reason plain-hashed passwords are considered broken; the fix there is salting, and it’s the fix here too.

We salt every IP hash with a value that isn’t part of the public dataset, which makes precomputed reverse-lookup attacks impractical — an attacker would need to rebuild their entire lookup table per salt, for a search space that’s already enormous. This is the difference between “technically hashed” and “actually resistant to the attack hashing is supposed to prevent.”

What this gets you, and what it doesn’t

Hashed, salted IPs let us do real aggregate analytics — country-level geography, rough traffic patterns, “is this bot traffic or human traffic” — without a plaintext IP ever sitting in our database. What it doesn’t do is make your traffic literally untraceable if someone were determined enough and had other data to correlate against; no anonymization technique operating on a single data point in isolation can promise that, and we’re not going to claim otherwise.

The honest version of this claim is: we don’t store IPs in a form that identifies you, and we’ve specifically defended against the known way naive hashing fails. That’s a real, meaningful guarantee. It’s also a narrower one than “your traffic is anonymous,” which is why we’d rather say the specific thing than the reassuring thing.