What is my IP

Why your browser cannot answer this on its own

A page like this one looks as though it ought to be able to read the answer off the machine it is running on, and it cannot. Nothing in the browser platform exposes the address you reach the internet from — there is no property to read and no permission to grant. The address your own machine holds is almost never the one you are asking about: behind a home router it is a private number that the router rewrites on the way out, and on a mobile network it may be rewritten a second time by the provider. The one browser feature that ever leaked an address at all was WebRTC, which gathered the machine’s own addresses in order to set up a call, and every current browser now hides even that behind a random name ending in local. So the number was never available through the platform, and what little used to leak was the wrong number anyway.

The address you actually mean is not a property of your computer. It is what the far end of a connection sees when your traffic arrives, and it belongs to whatever equipment last rewrote it on the way — your router, your provider’s shared carrier-grade NAT, a VPN exit, a corporate proxy. It exists only in the eyes of a server you have contacted. That is why the only way to learn it is to contact one and ask what it saw, and it is why this page asks three times rather than once.

• It is not the address your operating system shows for your network adapter. That one is usually private — a 192.168 address, a 10 address, a 172.16 address — and it means something only inside your own network. Nothing on the far side of your router ever sees it.
• It is not permanent. Most home connections are handed an address that can change when the router reconnects or when the provider decides, and a mobile connection can change it as you move. An address you wrote into a firewall rule last month may already belong to somebody else.
• It is not necessarily one number. On a network that carries both families you have an IPv4 address and an IPv6 address at the same time; they are unrelated numbers, issued by different parts of the same provider, and they travel by different routes.

This is also why the answer is not in the page source, and why looking there finds nothing. Every page on this site is written out as a flat HTML file when the site is built, long before you open it, and the only address available at that moment is the build machine’s — which is nobody’s business and certainly not yours. So the file that reaches you carries the explanation and three labelled, empty slots, and the readings are filled in afterwards, by your own browser, from your own connection. If you view source and find no address, you are reading the design rather than a bug.

Two families, and why only one of them may answer

IPv4 and IPv6 are two separate systems of addresses, and any one connection uses exactly one of them from end to end. IPv4 addresses are the familiar four numbers separated by dots, and the supply of them ran out years ago; IPv6 addresses are the long ones written in hexadecimal groups separated by colons, and there are more of those than anybody will use. Most networks now carry both at once — that is what dual stack means — and on such a network you hold an address in each, with no arithmetic relationship between them whatever.

That is what makes a single reading half an answer, and it is the trap almost every tool of this kind falls into. This site’s name carries both an IPv4 and an IPv6 record, so your browser picks one of the two before any code here runs, and a tool that only asks “what address did this arrive from” learns about that family and no other. A reader who came looking for their IPv4 because a firewall rule needs one can be shown an IPv6, with nothing on the page to say that the other half exists, is missing, or was simply never asked about.

Pinning a family therefore means asking somewhere that has only one. Two of the three readings go to Cloudflare’s public resolver addressed by a written-out address rather than by name, and the written-out address is itself the pin: there is no name to look up, so there is no choice for the browser to make. A written-out IPv4 address can only be reached over IPv4 and a written-out IPv6 address only over IPv6, and the certificate covers the address, so each is an ordinary verified encrypted connection rather than a trick. Whatever comes back from the first is your IPv4 by construction, and whatever comes back from the second is your IPv6 by construction.

• You may simply not have the family. IPv6 is still not offered by every provider, on every plan, or on every router as it was shipped, and a network without it has nothing to report.
• Something in the way may stop it. A corporate firewall, a hotel network or a security appliance can refuse one family outright, or refuse this one endpoint while the rest of that family works perfectly.
• It may be blocked in silence rather than refused. A refusal comes straight back and the row says so; packets dropped without an answer look like nothing happening at all, which is why each reading is given a bounded wait and then given up on rather than left spinning.
• The endpoint may answer with something that is not an address. That is a different failure from silence and the row says which it was, because a tool that folded every shape of failure into one blank field would leave you unable to tell an unusual network from a broken page.

Undetermined is not the same as absent

Two situations matter more than any others here, and from a failed request they look identical: not having a family at all, and having it blocked on the way out. Tools of this kind report them identically, usually by showing nothing and letting you guess. This page keeps them apart, and the third reading is the entire mechanism for doing so. It goes to this site itself, which offers both families, so whichever one answered is the one your browser chose when the choice was free — and that single fact is enough to turn a silence into a conclusion.

• The family’s own endpoint answered. You have that family, its address is on the row beneath, and nothing else the page learns can overturn it.
• It did not answer, and your browser reached this site over that same family. Then you demonstrably have it — you are using it to read this sentence — and something between you and that one endpoint stopped that one request. The verdict is “could not be determined”, and the reason is written out beside it.
• It did not answer, and your browser reached this site over the other family instead. That is the only route to “you do not have it”, and it is the only circumstance in which this page will say so.
• It did not answer and neither did this site. Then there is no evidence in either direction, and “could not be determined” means precisely that: the tool learned nothing, which is a statement about the tool rather than about your network.

That is why a sentence sits under every verdict rather than behind a link or a tooltip. “Could not be determined” asks two completely different things of you depending on which of the two it is. One of them says that a family you certainly have is being blocked somewhere between your browser and one particular address, which is a thing to go and look at. The other says the run learned nothing and is worth taking again from a different network. A colour and a word cannot carry that difference, and a tool that guessed between them would be telling you something false about your own connection.

The third reading is worth reading for its own sake as well. It names the family your browser preferred for an ordinary name that offers both — the outcome of a race your operating system runs every time you open a page, decided by neither of you and configured by nobody — and no comparable tool reports it. It is also the fact both verdicts above were cross-checked against, so it is on the page rather than hidden inside the reasoning: a reader who would rather audit a conclusion than trust it can see the evidence it was drawn from.

Why the two rows are allowed to disagree

Each reading carries more than an address. The same answer reports the country the endpoint placed that address in, the Cloudflare datacentre that responded, the version of the encrypted transport, the version of HTTP the request used and whether the connection came through Cloudflare’s own WARP client. Those are printed per row and never merged into a single summary, because the rows genuinely disagree: while this tool was being designed one machine, at one moment, reached a datacentre in London over IPv6 and one in Israel over IPv4. Neither reading was wrong, and neither network was faulty.

• Country is where the endpoint places the address that arrived, which is a lookup performed on the address rather than any knowledge of you. A VPN moves it, and so does a provider that hands out addresses registered in a neighbouring country.
• Datacentre is the Cloudflare site that answered, as a three-letter code in the style of an airport. Each of these endpoints is announced from many places at once and the one you reach is chosen by internet routing — separately for each family, which is why this is the row that disagrees most often.
• TLS is the version of the encryption the connection settled on. It is negotiated per connection, so one row can differ from another without either being unusual.
• HTTP is the protocol version this particular request used. It too is settled per connection, and it depends on how the connection was made rather than on anything about your network.
• WARP says whether Cloudflare recognised the traffic as coming through its own client. For most readers this is off on all three rows, and it is here because a reader for whom it is not off would otherwise be puzzled by the country.

So read a row as an account of one connection and nothing wider. Two rows naming two datacentres are not a contradiction to be resolved; they are two answers about how your two families leave your network, which is exactly the thing a tool showing one address cannot show you. It is also the reason these facts are attached to rows in the first place: collapsing them into one line would mean picking one of the two and printing it as though it described both.

Who is asked, and what this tool will not do

All three requests go to the same place: Cloudflare’s trace endpoint, which answers with a short list of facts about the connection that has just arrived. This site is itself served through Cloudflare, so the operator being asked is the one that has already seen your address — it saw it when this page loaded, before a line of the page’s own code ran. The three requests ask aloud for something that was handed over in silence a moment earlier, and they hand it to nobody new. That is why they are made automatically rather than behind a button: a consent gate in front of them would cost you the answer you came for and buy you nothing at all.

That argument is specific, and it is worth saying plainly that it is not a general licence, because the same sentence would be false about almost any other endpoint. It holds only while the party being asked is the party already serving the page. Point a tool like this at a third-party address service and the request stops being an echo and becomes a real disclosure to an operator who had nothing — at which point the reasoning would have to be made again from the beginning rather than quoted from here. That is one of the reasons this page does not use one.

Nothing you type is sent anywhere, for the simple reason that there is nothing here to type: the page has no input at all. No address is stored, none is kept between visits, and none is written into anything the page leaves behind. Pressing refresh takes all three readings again from the beginning and works out both conclusions afresh, which is what makes the page worth keeping open while a VPN goes on or off — and it is also the only thing that ever sends the requests a second time.

• It will not look up somebody else’s address. That needs a commercial geolocation database reached through a third party, which would mean handing an address to an operator who did not have it, and it is a different question from the one this page’s name asks.
• It will not name your provider, your autonomous system number or your city. None of that is in the answers this page receives, and obtaining it means the same third party as above.
• It will not show your local or private address. No current browser exposes it any more, and it was never the address people mean when they ask this question — it is the one their own machine already displays.

None of those is a gap waiting to be filled. Each would have to be bought with a dependency on somebody else’s database and somebody else’s continued goodwill, and paid for with the one thing this page is careful about. A tool that answers a single question completely — both families, with the evidence for each, and an honest silence where it has none — is worth more here than one that answers four of them partly.