Accuracy & tradeoffs
A prefix-based lookup loses some information compared to sending a full IP. This page explains exactly how much, what you get back, and how to tune the tradeoff for your use case.
"Won't a coarse prefix always produce a fuzzy result?"
Usually not. The concern is reasonable, but the data does not support it as a general rule.
The underlying database stores network blocks, not individual IP addresses. Blocks like 77.119.0.0/16 or 203.0.113.0/24 are the unit of data. ISPs and carriers allocate IP space in contiguous blocks, which means a /16 prefix very often maps cleanly to exactly one network owner.
We evaluated all 65,536 possible /16 blocks in the database. The result:
exactly one network
(manageable ambiguity)
(fragmented ranges)
In 83% of cases, sending 1.2.x.x resolves to a single network. Same country, same ASN, same result as a full IP lookup. No degradation.
You control the precision. Here are your options.
The more of the IP you expose, the fewer candidate networks BlurLoc has to consider. We sampled 100,000 random IPs and measured how often each prefix level produces exactly one match:
| What you send | Example | Single match |
|---|---|---|
| First octet only | 77.x.x.x | 21% |
| A.B prefix default | 77.119.x.x | 83.3% |
| A.B + 1 digit of C | 77.119.1x.x | 86.0% |
| A.B + 2 digits of C | 77.119.12x.x | 92.7% |
| Full IP (compat mode) | 77.119.123.45 | 100% |
The default A.B prefix (77.119.x.x) already delivers a single match in 5 out of 6 cases. For most applications, that is sufficient. Exposing one or two extra digits of the third octet pushes that to 93%.
When there are multiple candidates, you know exactly how many and how likely each one is.
BlurLoc does not hide ambiguity behind a single "best guess". Every response tells you:
- candidate_count — how many networks matched the prefix
- probability — the confidence score for the selected match
- match_type — whether this was an unambiguous exact match or a probable one
When probability: 1 and candidate_count: 1, the result is identical to a full IP lookup. No information was lost by using a prefix. That is the case 83% of the time at A.B level.
When probability is lower, you can treat the result as uncertain and handle it explicitly — fall back, show a default, or prompt for more context. You are not flying blind; you have a number.
The probability score is not a heuristic. It is exact.
When BlurLoc receives a prefix like 77.119.x.x, it:
- Treats the prefix as a region R in IPv4 address space (all 65,536 IPs in that /16).
- Finds every network block in the database that overlaps R.
- Computes the exact intersection size for each: how many of those 65,536 addresses fall inside this network block.
- Assigns each network a probability proportional to its intersection size.
This is a geometric calculation over address space, not a machine-learning estimate. It is exact given the database. If one network covers 57,000 of the 65,536 addresses in a /16, its probability is 57,000 / 65,536 = 0.87. That number is not approximate.
The one assumption: the model treats all addresses in the region as equally likely. Real traffic volumes per IP are not modelled. In practice, probability scores closely track what a full IP lookup would return — but you should treat low-probability results as uncertain.
The 9% problem: fragmented hosting and cloud ranges
Roughly 9% of /16 blocks contain more than 10 distinct network entries. These are almost always large hosting providers, cloud platforms, or CDN ranges where a single /16 is carved into many small allocations across different countries or organizations.
For those ranges:
- A /16 prefix will produce a low probability score and a high candidate count.
- Exposing one more digit (S3 pattern:
1.2.3x.x) often resolves the ambiguity significantly. - If the use case genuinely requires precision in those ranges and the compliance tradeoff is acceptable, compatibility mode (
?strict=0) lets you submit a full IP for those specific calls.
The signal: if probability is below your threshold and candidate_count is high, you are likely in a fragmented range. You can detect this programmatically and handle it per your application logic.
Which prefix level for which use case?
?strict=0) for that specific call path only. If you choose (2), that call is a standard full-IP data transfer and should be handled accordingly in your compliance setup.The bottom line
For most lookup use cases — country, ASN, VPN flag, hosting flag — a /16 prefix delivers the same answer as a full IP lookup 83% of the time. In the remaining 17%, you get a probability score that tells you exactly how confident the result is, and the option to step up precision if needed.
The question is not "is a prefix lookup as accurate as a full IP lookup in every case?" It is not. The question is: "is it accurate enough for the decisions I want to make, and does the precision I actually need require disclosing the full host address?" For most applications, it does not.
Try it in the playground with your own prefix patterns and inspect the candidate sets and probability scores before integrating.