A location request is the honest way to find someone: you ask, they answer, and nothing is revealed unless they choose to. This guide walks through the whole flow, from the text you send to the point that comes back with its accuracy range.
The short version
You enter a phone number. PingLocate sends that number a text with a link. The person opens the link, their browser asks for location permission, and if they accept, a single point comes back with its accuracy range. That choice is the whole mechanism. There is no app, no signup, and no way to skip the person’s choice.
Everything below is detail on that short version. If you only remember one line, it is that the request waits on a person rather than on a search, which is why a result here means something.
What the sender does
You start on the PingLocate tool, enter the phone number, and complete a quick verification. The request goes out once that is done.
When you send, PingLocate creates a unique link and delivers it by text message. You then wait. You are not told the person’s location at this point, because it does not exist yet.
The number can be typed in international or local format, and only the digits are read, so spaces, dashes, and brackets make no difference. The one thing worth checking is that the number still reaches the person you mean to ask, because the request travels to whoever holds it now. The request link does not expire on its own, so a request sent in the morning can still be answered in the evening.
What the link itself contains
The link is one web address that does two things. It identifies the request, which is how the answer finds its way back to the right request, and it opens a page that is able to ask the browser for a location. Those two jobs are all the link does.
What the link does not contain matters just as much. It carries nothing about your own location, so accepting a request tells the other person nothing about where you are. It carries no name and no number, which is why the message cannot say who sent it. And it does not install anything, so opening it starts nothing that outlives the page.
What the other person sees
They receive a normal text message with a link. The message does not show your phone number and does not name you. What they see is a request to share their location, from PingLocate.
The request does not reveal who you are. The decision to share is theirs alone.
It also does not pretend to be something else. The message says it is a request to share a location, so nobody receives one without knowing what it is. That is a deliberate trade: a request that announced your name might be answered more readily, and a request that hid its purpose would not be a request at all. If you want the person to know it is you, send a message of your own alongside it.
What happens when they tap
The link opens in their phone’s browser, not in an app. The browser shows the location permission prompt, the same one any website shows when it asks for location. If they allow it, the browser reads the device’s location and sends one point back. If they decline, nothing is sent, and nothing comes back.
This is the part that decides whether a result is real: a location is only ever shared after the person acts. Read our guide on whether phone trackers really work for why the instant claims do not hold up.
Three things can happen, and only one produces a result. They allow it, and one point comes back. They decline, and the page tells them the location was not shared. A third path is no answer at all: closing the page or leaving the prompt alone produces no result, and from your side that is indistinguishable from a decline, because in both cases no point arrived.
What you get back
When they accept, the shared point comes back with its accuracy range. That range matters: with GPS on, results are usually within tens of meters, but a device without GPS falls back to a network estimate that is city-level at best, with a range of several kilometers. The range comes with the result rather than being left out.
You get one point, not a live trail, and the point stays where it was taken. If the person walks away after accepting, the point does not follow, and there is no page to refresh for a new position. A second reading needs a second request and a second tap, which is the same rule as the first one rather than an exception to it. Continuous movement would need an app-based tool with ongoing permission.
What can go wrong, and what to do
- They never open the message. Messages get buried, and unknown senders get ignored. From your side this produces the same result as a decline.
- They decline the prompt. Nothing is shared, and there is no way around that, on your side or ours.
- The message never arrives. Carriers filter texts, and some phones block senders who are not in the address book.
- The number is a landline. A landline cannot open a link, so the request reaches nobody.
- Their phone is off or offline. The page cannot load without a connection, so the request waits. The link does not expire on its own, so it can still be answered once the phone is online.
- Location services are off on their phone. The permission can be allowed while the location setting is off, and the reading then usually falls back to a city-level network estimate, and sometimes there is none at all.
In every one of those cases the next move is the same, and it is not a setting you can change. Call the person, or send a message telling them a request is already waiting.
Why consent is the part that matters
Everything in this flow hinges on one fact: a phone number does not contain a location. A promise to show you a person’s exact location from their number alone, with no action from them, cannot be kept. PingLocate works because the person agrees, and that agreement keeps a request on the consent side of the line. A tool that overpromises has nothing to show at the end. If you want the legal picture, read our guide on tracking a phone legally.
The same fact explains why the request is built the way it is. Because the phone has to be asked, the person holding it has to be asked, and because they have to be asked, they can say no. A design that removed the question would not produce a location more reliably, only less often.
The request compared with the alternatives
There are three ways to answer the question of where someone is, each suited to a different situation.
Asking. A message asking where they are costs nothing, needs no tool, and often settles the question in one line. A request is worth sending once that has failed, or when a description would not be precise enough to act on.
A location request. This sits between asking and an app. It asks for one point rather than a description, which is more useful when the person cannot say where they are, and it asks less of them than an install does.
An app with ongoing permission. This is the right tool for a standing arrangement, because it can show movement over time. It asks both people for an install and a permission that stays open, which is the wrong shape for a single question asked once.
For your own lost phone, none of the three is the first step. The device finder built into iOS and Android locates a phone tied to your account and needs nobody’s cooperation. See how to find a lost phone.
If you want the tool-side steps before reading further, the Send a Ping feature sets them out in order.