HLR lookup vs MNP lookup vs number validation: what each one answers

Number validation, MNP lookups and HLR lookups answer three different questions. Validation asks whether the digits could be a real number. An MNP (mobile number portability) lookup asks which network the number belongs to today. An HLR lookup asks the home network whether the subscriber is live right now. Most teams need the first on every number and the others only where a wrong answer costs money.

#What does each check actually answer?

The three names get used as if they were grades of the same product. They aren't. Each one reads a different source of truth, so each one can be right while the others are silent.

A useful way to remember it: validation is about the number, MNP is about the network, and HLR is about the subscriber. The further down the list, the more you learn, and the more things can go wrong on the way to an answer.

#How does number validation work?

Validation is an offline calculation. Every country publishes a numbering plan that says which ranges exist, how long numbers are and which ranges are mobile, fixed, toll-free or premium-rate. The international frame for these plans is ITU-T Recommendation E.164 (ITU, 2010), which also caps a full international number at 15 digits.

Open-source libraries such as Google's libphonenumber (Google, 2026) package those plans as metadata. Given 07911 123456 and the country GB, they return +447911123456, say the number is valid, and give a range-based type such as MOBILE. It takes microseconds and costs nothing.

What validation cannot do is tell you whether anyone holds the number. A valid number may never have been issued. It may have been disconnected last year. The type is a property of the range, not of the current service, so a number ported from a landline to a VoIP provider still looks like a landline. See E.164 and the E.164 guide for developers for the pitfalls.

#How does an MNP lookup work?

When a subscriber keeps their number and moves to another operator, the number no longer lives on the network its range was allocated to. Regulators made this a right: in the US, wireless portability has existed since November 2003 in the largest metropolitan areas and since May 2004 elsewhere (FCC), and the EU's electronic communications code requires porting in Article 106 (EU, 2018).

To route calls and texts, networks keep track of ported numbers. Many countries run a central porting database; others make each operator keep its own copy. An MNP lookup reads that data, directly or through a regularly refreshed replica, and returns the current network and usually a "ported" flag.

It answers "who serves this number?" well. It does not say whether the phone is on, whether the line is still in service, or whether the subscriber is abroad. Because the data is copied, a very recent port can take a while to show up. The portability post explains why prefix-based carrier guesses fail.

#How does an HLR lookup work?

An HLR lookup asks the mobile network itself. Every operator keeps a register of its subscribers: the Home Location Register in 2G and 3G, with successors in 4G and 5G. When an SMS is delivered between networks, the sending side first asks the recipient's home register where to send it, using the MAP protocol specified in 3GPP TS 29.002 (3GPP). An HLR lookup makes the same kind of routing query without sending a message.

The reply shows whether the number is assigned, whether the subscriber is currently attached to a network, which network holds the subscription (so porting) and whether it is a foreign network (so roaming). Nothing appears on the handset.

Its limits are practical. It works for mobile numbers only. Some operators block or mask external queries, and some return generic answers to protect subscribers, so a good service reports those cases as unknown rather than guessing. Raw replies can include identifiers such as the IMSI or the serving switch, which should never leave a telecom environment. See the HLR lookup glossary entry.

#How do cost and speed compare?

We won't quote market prices or response times here, because they vary by country, route and volume, and any single number would be misleading. The relative order is stable, though, and it follows from how each check works.

The practical consequence: run validation on everything, because it is free and removes junk before you pay for anything. Spend on network data only where the answer changes what you do next.

#Which check should you use when?

Pick the cheapest check that answers the question your workflow actually asks. This decision table covers the common cases.

If you are unsure, start with validation and line type, measure how many messages still fail, and add a live check where the failure rate justifies it.

#What does MobileValidate offer for each?

Each layer maps to something you can call today, except the live one:

• Validation and normalization happen on every request, free. Each result carries e164, country and number_status (valid, invalid_number, duplicate, suppressed). Invalid and duplicate rows are never checked or charged.
• Network data comes from the carrier lookup: line_type, the current carrier, country and, when it differs, original_carrier, which is the porting signal. For US and Canadian numbers, where porting between landline, mobile and VoIP is common, the US/CA carrier lookup runs in bulk jobs.
• Live network status, the HLR lookup, is coming soon. It will return status, ported, roaming (true or false only, never a location), network, mcc_mnc and country, and never the IMSI or serving switch.

One request can combine several checks. Here is a real test-mode call:

curl https://api.mobilevalidate.com/v1/lookup \
  -H "Authorization: Bearer $MOBILEVALIDATE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"numbers": ["07700 900001", "12345"], "checks": ["carrier"], "default_country": "GB"}'

Response (excerpt, test mode: the two items of results):

[
  {"input": "07700 900001", "e164": "+447700900001", "country": "GB", "number_status": "valid",
   "checks": {"network.carrier": {"status": "completed", "registered": true,
     "attributes": {"line_type": "mobile", "carrier": "Test Carrier", "country": "GB"},
     "billed": false, "reason": null}}},
  {"input": "12345", "e164": null, "country": null, "number_status": "invalid_number"}
]

The invalid number never reaches a check. With a live key it would not be billed either.

#How should you read the answers together?

The layers disagree in predictable ways, and the disagreements are informative:

• Valid, but carrier data is unknown. The number fits the plan, but no data exists for it. That can mean a new range, a small operator or a number never issued. The result is free; treat it as "no evidence", not as "fake".
• original_carrier differs from carrier. The number was ported. Normal on its own; worth a look only together with other signals, such as a password reset minutes later.
• Range says mobile, lookup says VoIP. The number moved to an internet-telephony service. The lookup wins, because it describes the number today. See VoIP detection for sign-ups.
• Valid mobile, unreachable in an HLR reply. The phone is off or out of coverage. One unreachable answer means "try later"; repeated ones over weeks suggest an abandoned number.

Store checked_at with every answer. Network facts change, and a decision is only as good as the age of the data behind it.

#What are the key takeaways?

• Validation is free and offline. It checks the digits against the numbering plan, not whether anyone holds the number.
• MNP tells you the current network. It fixes routing and pricing mistakes caused by ported numbers.
• HLR asks the home network. It is the only one of the three that says whether a mobile subscriber is reachable now, and it doesn't work for landlines or most VoIP.
• Run validation on everything; add network checks where a wrong answer costs more than the check.
• In MobileValidate: normalization on every request, carrier lookup for line type and porting hints, HLR lookup coming soon. You're not charged for inconclusive results (unknown, unsupported country, timeout, invalid, duplicate). See pricing.

For a step-by-step view of what "active" means, read how to check if a phone number is active.