IP Lookup & Geolocation

What an IP lookup actually tells you

IP geolocation is approximate, not surveillance-grade. The data comes from public registries (RIRs like ARIN, RIPE, APNIC) cross-referenced with ISP-published location data and crowd-sourced datasets.

What's accurate

• Country is essentially always correct (99%+).
• ISP / ASN is also reliable — this comes straight from the regional internet registries.
• Timezone is usually right.

What's fuzzy

• City is approximate. Often it's the city of the ISP's central office, not where the IP is physically used. A Comcast IP in rural Vermont might "geolocate" to Boston or Burlington.
• Latitude/longitude is similarly fuzzy — accurate to about a city/county, not a street.
• VPN and proxy IPs show the location of the VPN exit node, not the user. (That's the whole point.)
• Mobile carriers often show only the regional gateway, which can be hundreds of miles from the actual phone.

What it doesn't tell you

• The owner's name. ISPs don't publish customer info.
• Their physical street address. Geolocation databases work at city level only.
• What they're doing on the internet. The IP is just a routable identifier.

What ASN means

Autonomous System Number — a globally unique identifier for an organization that controls a chunk of the internet. AS7922 is Comcast. AS15169 is Google. AS13335 is Cloudflare. Looking up the ASN tells you which network operator owns the IP, which is more reliable than city-level geolocation.

Reading the results, field by field

People sometimes look at an IP lookup result and take every field at face value. After twenty-plus years running networks for small businesses in northern Vermont, I can tell you: some fields are gospel, some are educated guesses, and a couple are essentially decorative. Here's how I actually read each one when I'm investigating a real problem — a suspicious login from a customer's account, an inbound VoIP call from a spoofed number, a blocked IP that shouldn't be blocked.

The IP address itself

Obvious, but worth pausing on. An IPv4 address is four numbers between 0 and 255 separated by dots (like 174.169.13.15). An IPv6 address is eight groups of four hexadecimal digits separated by colons (like 2606:4700:4700::1111), usually shortened by collapsing runs of zeros with the double-colon. If you see an address that starts with fe80:, that's link-local — it only works on your local network segment and can't be routed on the public internet. If it starts with ::ffff:, that's an IPv4 address wearing an IPv6 costume, which mostly happens in dual-stack server logs.

Reverse DNS (PTR record)

This is the hostname the IP owner has published for their address. A residential Comcast IP might resolve to something like c-73-11-42-88.hsd1.vt.comcast.net. That's not the customer's chosen name — it's Comcast's internal naming convention encoding the octets of the IP itself. Business connections often have meaningful reverse DNS: mail.example.com for a mail server, vpn.example.com for a corporate VPN gateway. Missing reverse DNS is unremarkable for consumer IPs but is a red flag for a sending mail server (Google and Microsoft will happily reject mail from an IP with no PTR record).

Country, region, and city

Country is derived from what regional internet registry allocated the IP block. ARIN covers North America, RIPE covers Europe and the Middle East, APNIC covers Asia-Pacific, LACNIC covers Latin America, AFRINIC covers Africa. Countries almost never change hands for an IP block, so country accuracy is around 99%. Region (state or province) is roughly as good — maybe 95% accurate for wired connections.

City is where it gets fuzzy. Geolocation databases combine what the ISP publishes with crowd-sourced data (browsers reporting locations, mobile devices with GPS). For a Comcast subscriber in Troy, Vermont, the result often shows Burlington or even Boston — the location of Comcast's regional office, not the customer's home. For AWS or Google Cloud IPs, the city is the location of the data center, which might be genuinely useful (Ashburn, VA for us-east-1) or completely misleading if the traffic is exiting through an anycast edge.

ISP and ASN

These come from the same registry data as country and are highly reliable. ASN is the more useful of the two because it's stable and unambiguous. Comcast's ASN is 7922 whether you're looking at a residential cable modem in Vermont or a business fiber connection in California. Every Cloudflare IP shares ASN 13335. When I'm chasing a security event, ASN is the first thing I care about — it tells me which network operator I need to contact if I want to file an abuse complaint, and it's the piece of data I use to categorize traffic in firewall rules.

The ISP name (the field labeled "org" or "isp" in most tools) is usually the plain-English version of the same information: "Comcast Cable Communications, LLC" corresponds to AS7922, "Google LLC" to AS15169, and so on. Occasionally the org and ISP names diverge — a small hosting company might resell IPs from a larger provider, and the ASN belongs to the parent while the ISP field names the reseller.

Timezone

Derived from the physical location the geolocation database thinks the IP is in. For fixed-location wired IPs, this is essentially always right. For mobile carriers, it might be wrong if the carrier's regional gateway is in a different timezone than the actual subscriber. For datacenter IPs, it reflects the data center's timezone, not the operator's headquarters.

Network type

Not everyone shows this and there's no standard classification, but it's one of the more useful derived fields. A well-built classifier looks at the ASN and org name and buckets the IP into categories like residential ISP, mobile carrier, business connection, cloud data center, known VPN provider, Tor exit node, or CGNAT range. My tool uses a curated list of ASN-to-category mappings, updated when new large operators appear — Starlink's SPACEX-STARLINK ASN, for example, went from unclassified to "satellite" once it had real subscriber counts.

Practical scenarios: when I actually pull up an IP lookup

Scenario 1: A customer's Microsoft 365 account gets flagged for suspicious sign-in

The alert shows a login from an IP the customer's user has never used. First thing I do: run the IP through here. If the result comes back as "United States, residential ISP, Comcast" and the customer is in Vermont, and I can talk to them and confirm they were at home yesterday afternoon, we're probably fine — that's likely just a mobile hotspot or a router that got a new IP from Comcast's DHCP. If the result comes back "Russia, datacenter, known VPN provider," I lock the account first and ask questions after.

The trick is not to over-index on any single signal. Legitimate users routinely trip on cloud or datacenter IPs because they're on a corporate VPN, using iCloud Private Relay, or connecting through a mobile carrier that happens to route through a data center. False positives are exhausting for everyone. But the combination of geolocation, ASN, and network type is usually enough to make a defensible judgment.

Scenario 2: A VoIP customer's PBX is getting hammered by SIP registration attempts

When I'm running a FreeSWITCH or 3CX system for a customer and their logs fill up with SIP INVITE floods, I run the source IPs through here to see what network they're on. Almost always it's either a residential IP from a country the customer doesn't do business with, or a known VPS provider (DigitalOcean, Vultr, OVH) that hobbyists use to script attacks. Once I know the pattern, I can write firewall rules that block whole ASNs or entire regional registries. Blocking AS7922 (Comcast) would block a lot of legitimate US traffic, but blocking a small VPS provider's ASN blocks 99% of a specific attack profile with essentially no legitimate impact.

Scenario 3: An email lands in junk and the customer wants to know why

I look up the sending IP. If the reverse DNS is missing or generic (like an AWS EC2 hostname), that alone is enough to explain some of the delivery issues. If the IP geolocates to a datacenter and the sender is claiming to be a small business, mail providers get suspicious — legitimate small-business email usually flows through a well-known mail provider (Google Workspace, Microsoft 365, Fastmail) whose IPs are established senders. An IP with no reverse DNS, no established sending reputation, and a datacenter classification is going to have a rough time landing in inboxes no matter what SPF and DKIM say. I built the Email Health Check tool specifically for this workflow — it flags most of the same issues in one shot instead of manually inspecting each field.

The privacy-and-accuracy honest talk

There's a persistent internet myth that IP addresses reveal your street address. They don't. What they reveal is what your ISP publishes to the regional registry, which is typically city-level and often wrong even at that resolution. Law enforcement, with a subpoena, can go to your ISP and ask "who was assigned IP X.X.X.X at 3:47pm on Tuesday?" and the ISP will tell them. But nothing about that flow is available through public IP lookup tools — including this one.

What we do have access to, and what I'll show you honestly:

• Country and region: from the RIR allocation records. Public. Reliable.
• ISP and ASN: same source. Public. Reliable.
• Approximate city: from geolocation databases that combine RIR data with crowd-sourced info. Public but often wrong.
• Timezone: derived from location. Usually right for wired IPs, often wrong for mobile or satellite.
• Reverse DNS: whatever the IP owner has published. Public.

And what we absolutely don't have:

• The account holder's name or contact info. This is not in any public database.
• Their street address. Even if the ISP publishes to the block level, that's the ISP's office, not the subscriber.
• What they're doing online. IP addresses are routing labels, not activity logs.
• Whether they're the actual person using the IP. A household might have ten devices behind one public IP, and any of them could be the one that made a given request.

Edge cases worth knowing about

CGNAT (Carrier-Grade NAT)

Many mobile carriers and some rural ISPs put dozens or hundreds of subscribers behind a single public IP. If you're on Starlink or a cellular data plan, your "public" IP is probably shared with a lot of other subscribers. This means IP-based rate limiting, IP-based bans, and IP-based geolocation are all coarser than they used to be. If a customer says their IP just changed, and the new one shows the same ISP and same geolocation but a completely different address, that's often CGNAT reassignment. My CGNAT Detection tool checks specifically for this by comparing your public IP against known CGNAT ranges (RFC 6598, which reserves 100.64.0.0/10 for this purpose).

iCloud Private Relay

Apple's Private Relay feature, on iCloud+ subscriptions, routes Safari traffic through two hops — first through Apple's network, then through a third-party partner (Cloudflare, Akamai, or Fastly). The result is that a Vermont Comcast subscriber using Safari on their iPad shows up as, say, an anonymized Cloudflare IP in Boston. The geolocation is deliberately approximated — Apple tries to keep the country and region roughly correct so location-aware services don't break, but city and street are hidden. If you're seeing an unusual number of "Cloudflare" or "Fastly" residential-looking traffic, some of that is Private Relay.

Tor exit nodes

Tor traffic exits the Tor network through publicly-known exit nodes. The Tor Project publishes the exit node list, so any IP lookup that classifies network types can flag these. If you see an inbound login attempt from a Tor exit node, that's essentially always someone trying to hide their identity — occasionally a privacy-focused legitimate user, more often a security threat. My classifier will label these as Tor when it recognizes them, but the exit node list changes daily and the classifier's data may lag by a few hours.

Corporate VPNs and cloud proxies

A user connecting through a company VPN will show the VPN concentrator's IP, not their home IP. Similarly, someone using a security-oriented proxy service like Zscaler, Cloudflare Zero Trust, or Netskope will show that provider's IP. These are increasingly common in enterprise environments and can look identical to consumer VPN services in an IP lookup — the difference is usually only visible if the corporate VPN has a dedicated ASN or a distinctive reverse DNS pattern.

When this isn't the right tool

An IP lookup gives you a snapshot of who a particular IP belongs to right now. It doesn't tell you:

• Whether the IP is on an email blacklist. For that, use the DNSBL Blacklist Check — it queries six major real-time blocklists in parallel and tells you if your sending IP is flagged.
• What ports the IP has open. IP lookup is registry data, not a port scan. Port scanning without permission is often against the law where you're doing it from, so I don't build tools for that.
• Whether a whole domain is legitimate. If you're investigating a domain (not just an IP), start with WHOIS Lookup to see the registrar and registration date. A domain registered three days ago sending you invoices is almost certainly a phishing operation regardless of what its IP resolves to.
• Historical ownership. IP blocks change hands. If AS12345 owns the block today but AS67890 owned it two years ago, current-time IP lookups can't tell you the history. Passive DNS databases (SecurityTrails, DNSDB) track this but require paid subscriptions.

How this tool works under the hood

When you look up your own IP with no argument, the lookup uses Cloudflare's edge geolocation data — the same data Cloudflare uses to serve country-specific content on millions of sites. It's fast, accurate, and comes at no external API cost, so I can offer it without rate limits.

When you look up a specific IP with the ?ip= parameter, the request goes through my Cloudflare Worker to a commercial IP data provider. Results are cached in Cloudflare's KV store for 30 days per unique IP, so repeat lookups (yours or anyone else's) skip the external API entirely. This makes the tool fast for popular IPs and keeps my monthly API budget under control. If the primary provider is rate-limited or has an outage, the worker falls back to a secondary provider so you still get a result — the underlying data will be slightly different but the same fields are populated in the same shape.

Reverse DNS is queried separately through Cloudflare's DNS-over-HTTPS endpoint, in parallel with the geo lookup. This is why a lookup that returns geo data instantly might take another second to fill in the hostname — the PTR query is a separate round trip to whatever DNS server is authoritative for the IP's reverse zone.

Nothing about your session is logged. Cloudflare's edge sees the request the same way it sees any other request to any site behind their network. There's no analytics beyond Cloudflare's aggregate visitor counts. The IP data provider knows we looked up an IP but doesn't know who "we" is beyond "a Cloudflare Worker on the myipcat account."