HLRLookup:WhatItReturnsandHowtoUseIt

An HLR lookup asks a mobile operator's own subscriber database whether a phone number is switched on and reachable right now, and which network is currently serving it. It does this without sending an SMS and without ringing the phone. That combination, live truth with no contact, is why HLR sits underneath so much SMS routing, signup verification, and fraud scoring work.

This guide covers what the Home Location Register actually is, what a query returns field by field, where HLR differs from a carrier lookup, what a free HLR lookup can and cannot tell you, and how to call the API without wasting credits. If you want to run one right now against a real number, the free HLR lookup tool takes an E.164 number and no signup.

What the Home Location Register actually is

Every mobile network operator runs a central subscriber database. In GSM and 3G networks it is called the Home Location Register (HLR). In LTE the equivalent is the Home Subscriber Server (HSS), and in 5G core networks it is the Unified Data Management function (UDM). The name changed across generations, but the job did not: it is the authoritative record of every SIM the operator has issued and the current state of each one.

For each subscriber the register holds:

• The MSISDN, which is the dialable phone number.
• The IMSI, the identifier tied to the SIM. The IMSI begins with a Mobile Country Code (MCC) and Mobile Network Code (MNC) that together name the issuing operator.
• The service profile, meaning which services the SIM is entitled to use.
• A pointer to the switch currently serving the subscriber. This is how the network knows where to deliver an incoming call or message.

That last field is the interesting one. When a handset registers on a network, whether at home or roaming abroad, the visited network tells the home register where the subscriber now is. The register is therefore continuously updated by the network itself as a side effect of normal operation. Nobody maintains it as a list. It is operational infrastructure, which is precisely why it is more current than any file you can buy.

How a live HLR query works

An HLR lookup is a query sent over the operator signaling network using MAP, the Mobile Application Part of the SS7 protocol stack, or its Diameter equivalent on newer cores. Two MAP operations do most of the work:

• SRI-SM (Send Routing Info for Short Message) is the operation an SMS center normally issues before delivering a message. It asks the home register where to route the message. An HLR lookup service issues the same query but stops there and never sends the message, which is why the subscriber sees nothing.
• ATI (Any Time Interrogation) asks for subscriber state directly, including whether the handset is currently attached to a network. Not every operator permits ATI from outside, so availability of the richest fields varies by network.

Two things follow from this design, and both matter in practice.

First, the answer is genuinely live. It reflects the register at the moment of the query, not a snapshot from a nightly file. A number ported to a new carrier last Tuesday returns the new carrier. A handset switched off ten minutes ago returns as absent.

Second, the query is silent. Because it stops before message delivery, the handset never rings, no SMS arrives, and there is no per-message carrier charge. That is the difference between verifying a list of 200,000 numbers and paying to text 200,000 numbers to find out which ones bounce.

What an HLR lookup returns, field by field

A result is a small set of signals. Each one answers a different operational question.

Connectivity status. The headline field. Common values and what they mean:

Status	What it means	What to do with it
Active / connected	The SIM is registered on a network and reachable now	Safe to message or call
Absent / unreachable	The number is valid and provisioned, but the handset is off, out of coverage, or detached	Retry later, do not discard
Invalid MSISDN	The number is not allocated on that network	Remove from the list
Unknown	The operator did not return a usable answer	Treat as unresolved, not as a negative

The distinction between "absent" and "invalid" is the one teams most often collapse, and it is expensive to get wrong. Absent is a temporary state and those numbers are still good. Invalid means the number does not exist as far as the network is concerned.

Country and network codes. The MCC identifies the country and the MNC identifies the operator within it. Together they name the network precisely, which matters because operator brand names are ambiguous and change with mergers and MVNO deals, while MCC/MNC pairs do not.

Line type. Whether the number is a mobile line at all. Landlines and most VoIP numbers have no HLR entry, so a lookup on them cannot return connectivity. That is a boundary, not a bug: if you need coverage across every line type, pair HLR with phone validation, which handles the non-mobile cases.

Ported status, plus current and original carrier. Number portability means the operator that issued a number is often not the operator serving it today. Prefix based tools that map a number range to a carrier get this permanently wrong, because the prefix never changes. The register knows the truth, so a lookup returns both the original network and the one currently responsible.

Roaming network and country. If the subscriber is registered on a visited network, the result names it. For international messaging this drives routing and cost. For fraud work it is a mismatch signal worth scoring: a number claiming to be local while registered on a network on the other side of the world is a fact worth knowing before you approve a transaction.

IMSI and routing detail. The subscriber identity and the routing information the network would use. This is the deepest layer, used mostly by teams doing their own least cost routing or interconnect work.

HLR lookup versus carrier lookup

These two get used interchangeably and they are not the same thing.

A carrier lookup answers "which network owns or serves this number?" It resolves the operator, usually the line type, and often the country. Good implementations consult portability data so the answer survives porting. It tells you nothing about whether the handset is switched on.

An HLR lookup answers "is this number live on the network right now, and where?" It includes the carrier answer, then adds the state only the register knows: reachable or absent, roaming or home.

The practical rule is about cost and question. If you are segmenting a list by operator or filtering VoIP before an outbound campaign, carrier lookup is the cheaper, sufficient answer. If the decision depends on whether a specific handset can receive something in the next few seconds, such as a one time passcode at signup or a high value SMS send, you want a live HLR lookup. Plenty of teams run both: carrier data to shape the list, HLR at the moment of send.

For the wider picture of how these fit alongside CNAM and reverse directory data, see reverse phone lookup and HLR lookup explained.

What a free HLR lookup can and cannot do

"Free HLR lookup" is a real search because the query genuinely can be run for free on a single number. It is worth being precise about where the line falls, because the free tools that exist are not all the same.

A free lookup, including the 1Lookup free HLR tool, runs the same live query and returns:

• Connectivity status, meaning active, absent, invalid, or unknown
• The number's country
• Whether it is a mobile number
• Whether it has been ported

That is enough to answer "is this one number alive?" and it is genuinely useful for a support ticket, a suspicious signup, or a sanity check before you call someone.

What free lookups do not give you:

1. Carrier detail. Current versus original carrier and MCC/MNC network codes sit behind an account, because those are the fields that make the data commercially useful.
2. Roaming carrier and country, plus IMSI level routing detail.
3. Volume. Free tools are rate limited. Checking ten thousand numbers one at a time in a browser is not a workflow. Bulk and programmatic access is what the API is for.
4. A guarantee. Free tools are best effort. If a lookup is load bearing for revenue or compliance, you want the account, the logs, and the support path.

One more limit applies to every HLR lookup, free or paid: it does not return the subscriber's name, street address, or GPS position. The register holds the serving network and the location area used for routing, not a person's identity or a map pin. Any tool claiming to return a name and address from an HLR query is not reading an HLR.

Where HLR data earns its keep

SMS and A2P list hygiene. Run the list before the campaign, drop the invalid numbers, hold the absent ones for a retry. You stop paying to send messages into the void and you stop generating the failure rates that damage sender reputation. This is the most common reason teams adopt HLR, and the arithmetic is simple: a lookup costs a fraction of a send, so any meaningful share of dead numbers pays for the check.

Signup and one time passcode verification. Call the API when a user submits a phone number, before you issue the passcode. If the number is invalid you can say so in the form rather than after a failed send, and if it is absent you can offer a different channel. Fewer failed verifications, fewer abandoned signups, less wasted SMS.

Fraud and risk scoring. HLR fields are inputs, not verdicts. A number that is invalid, recently ported, or registered on a roaming network inconsistent with the stated country is a reason to look harder, not a reason to block on its own. Combine it with the rest of your signal set through fraud detection rather than treating any single flag as decisive.

Routing and interconnect. Operators, MVNOs, and messaging platforms use the serving network and ported status to pick the right route. Getting the destination network wrong means paying for a worse path and delivering less.

Calling the HLR lookup API

A request takes a number in E.164 format and returns the network's answer:

const response = await fetch('https://api.1lookup.io/v1/lookup/hlr', {
  method: 'POST',
  headers: {
    'Authorization': 'Bearer YOUR_API_KEY',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    phone: '+14155552671',
    include_roaming: true,
    include_network_info: true
  })
})

const result = await response.json()

A few implementation notes that save real money.

1. Always send E.164. A leading plus, the country code, then the national number, with no spaces, dashes, or national trunk prefixes. Ambiguous formatting is the most common cause of a lookup routing to the wrong network or failing outright. Normalize before you query, not after you get a bad answer.
2. Cache carefully, or not at all. Carrier and ported status are reasonably stable and can be cached for hours or days. Connectivity status is not, since it changes every time a handset goes into a tunnel. Caching reachability defeats the point of asking. If your decision depends on "right now," query at decision time.
3. Treat unknown as unknown. When an operator does not answer, the right behavior is almost never to mark the number bad. Fall back to a cheaper signal, retry on a schedule, or let the number through with a flag. Silently converting "we could not tell" into "invalid" will quietly delete good customers from your database.
4. Handle failure without blocking the user. Wrap the call in a timeout and decide in advance what happens when it expires. In a signup flow, letting the user proceed with a flag is usually better than a hard stop on a lookup that took too long.
5. Batch the offline work. One at a time is for real time decisions. List cleaning should go through bulk processing so you are not paying latency per row. Our bulk phone validation guide covers the batching patterns.

Coverage and cost

1Lookup runs HLR queries against 800+ mobile operators across 195+ countries, with typical response times under 300ms. Coverage is not uniform, and no honest provider will claim it is: some operators expose richer subscriber state than others, and a few restrict the deepest fields entirely. Expect connectivity and network identification broadly, and expect roaming and IMSI level detail to vary by network.

On pricing, one universal credit buys a full phone lookup, and the same credits also cover email verification and IP lookups, so you are not managing separate balances per data type. There is a 7-day free trial to test against your own numbers before committing, and current pricing has the volume tiers.

Where to start

If you have one number to check, run it through the free HLR lookup and read the connectivity field. If you have a list or a signup flow, the HLR lookup API is the same query with the full result set, bulk processing, and the carrier and roaming fields the free tool holds back.

The thing worth deciding up front is which question you are actually asking. "Which network is this?" is a carrier lookup and it is cheap. "Can this handset receive something right now?" is an HLR lookup, and it is the only check that answers it without sending anything.

If you are deciding which checks belong in your stack at all, and in what order, the complete phone number validation guide covers the full layer stack (format, range, carrier, live network) and where each one is worth paying for.