IP Address Lookup
Look up any IP address or domain for geolocation, ISP, ASN, and timezone — with a built-in location map, hostname resolution, and a session-local history of recent lookups. Detects your own public IP automatically.
Getting Useful Data Out of an IP Lookup
- Check the ASN, not just the city, when investigating traffic. A city can be a guess; an ASN like Amazon Web Services or DigitalOcean tells you definitively that a request came from a cloud server, not a home connection.
- Type a domain instead of hunting down its IP first. With Resolve Hostnames on, entering example.com resolves and looks it up in one step, which is faster than running a separate DNS lookup tool first.
- Don't treat the map marker as a precise address. It's the centroid of a registered IP block, useful for country and region context, not a GPS pin on a specific building.
- Turn off Save Recent Lookups before sharing your screen. The history list is convenient for repeated investigation work but visible on-screen — worth clearing if the IPs you're checking are sensitive.
Features
Where the Geolocation Data Actually Comes From
An IP address like 104.26.12.54 carries no location information by itself — it's just a number. What makes a lookup possible is the registration record behind it: regional internet registries track which organization controls each block of addresses, and that organization's own registered address, network footprint, and routing announcements let geolocation databases infer a probable country, region, and city.
The Autonomous System Number attached to a result is often the most reliable piece of that picture. AS15169 is Google's own network; AS16509 belongs to Amazon Web Services; residential ISPs carry their own distinct ASNs. Recognizing whether an ASN belongs to a cloud provider, a CDN, or a consumer internet connection is frequently more actionable than the city name sitting next to it — a "visitor" arriving from an AWS-owned ASN is almost certainly a server, not a person.
The precision of that data also varies with how densely an ISP has documented its own address allocations. Large fixed-line providers in well-mapped regions tend to register sub-blocks down to a specific city or even neighborhood, while some mobile carriers and smaller regional ISPs register an entire national block against a single head-office coordinate. Two IPs from the same country can land with very different confidence depending on which side of that gap the underlying provider falls on — one more reason ASN and organization name are worth reading alongside the city field rather than instead of it.
Typing a Domain Name Instead of an IP Address
Most IP lookup tools require an actual IP address as input, which means checking where a domain is currently hosted takes two separate steps: resolve the domain to an IP somewhere else, then paste that IP in here. Turning on Resolve Hostnames collapses that into one step — enter example.com directly, and the tool queries a public DNS-over-HTTPS resolver for its current A or AAAA record before running the geolocation lookup against whatever IP comes back.
This is a genuinely common need: confirming which CDN a competitor's site sits behind, checking whether a staging domain's DNS has actually propagated to the new server yet, or verifying that a client's custom domain is correctly pointed at the expected hosting provider. The result page notes which domain the shown IP was resolved from, so it's always clear whether you're looking at a direct IP or a resolved one.
The resolution itself runs over DNS-over-HTTPS rather than a traditional plaintext DNS query, which means the lookup request travels as an ordinary encrypted HTTPS call instead of the unencrypted UDP packets a standard DNS resolver would send. That's a meaningful difference on a shared or public network, where plaintext DNS queries can otherwise be read by anything sitting between the browser and the resolver. It also means the resolution step works from any network that allows normal web traffic, without depending on whatever DNS server a particular Wi-Fi or corporate network happens to hand out.
What Geolocation Can't Tell You
IP geolocation is inherently probabilistic. Country-level accuracy is genuinely excellent — typically above 95%, since large address blocks are allocated to specific countries as a matter of registry policy. City-level accuracy drops meaningfully from there: 70-80% is a realistic ceiling for residential connections, and mobile carrier IPs frequently geolocate to a regional hub city rather than wherever the phone actually is.
A VPN or corporate proxy changes the picture entirely rather than degrading it — the lookup correctly reports the VPN exit server's location, because that's genuinely where the traffic is coming from as far as the internet is concerned. And private address ranges (10.x.x.x, 192.168.x.x, and similar) were never assigned to any real-world location at all, which is why the tool flags them immediately instead of sending a lookup that could only fail.
That upfront check matters more than it sounds like it should. A raw list of server access logs frequently contains private addresses mixed in with public ones — internal load balancers, container networking ranges, health-check probes from inside the same data center — and treating every entry as worth an external geolocation request wastes time on lines that were never going to resolve to anything meaningful. Catching those locally, before a request ever leaves the browser, keeps the results that do come back focused on addresses that can actually tell you something.
Where This Fits Into Real Engineering Work
The most common use is debugging: a production request fails or behaves unexpectedly, and knowing whether it originated from a cloud data center, a known VPN range, or an ordinary residential ISP changes what the actual problem probably is. Checking a server's own IP after a fresh deployment is another routine one — confirming it geolocates to the expected region matters for latency assumptions, CDN edge selection, and data residency requirements that some teams are contractually bound to. A server provisioned in the wrong region isn't always obvious from a hosting dashboard alone, especially with providers that offer several data centers under similar-sounding names — an independent geolocation check against the deployed server's actual public IP is a fast way to confirm the request matched the intended location before customer data starts flowing through it.
Security triage leans on the same data differently: reviewing access logs after an unusual spike and checking whether the source IPs cluster around a handful of ASNs known for hosting or proxy services is often faster than reading through a full log line by line. And for anyone integrating with a third-party webhook provider, verifying that delivery IPs actually fall within the provider's documented range — rather than assuming every request claiming to be from Stripe or GitHub really is — is a cheap, worthwhile check before trusting a payload. Building the request URLs for that kind of testing is easier with the URL Encoder/Decoder handling the query string encoding correctly the first time.
Recent Lookups exists specifically for this kind of session — working through a batch of ten or twenty suspicious IPs from a single incident, or checking a handful of servers across a deployment one at a time, without re-typing or re-finding each address after the page moves on to the next one. It's deliberately scoped to the current browser tab rather than saved permanently, since a log-triage session is usually a one-time investigation, not something that needs to persist as a standing record once the question it was answering has been resolved.