An IP geolocation result describes routed network context, not a person's exact physical position. That distinction matters because the same address can represent a home connection, a mobile carrier gateway, a cloud edge, a VPN exit, or a public resolver. This tool takes one public IP address, domain, or full URL and turns it into a compact location-and-network summary that is easier to read than raw lookup output.
When you paste a direct address, the package enriches that address immediately. When you paste a domain or URL, it extracts the host, resolves one current public address, and then geolocates that resolved address. The result package combines approximate place fields with network ownership details, reverse DNS when available, a map marker, and exportable table and JSON views.
That combination is useful in ordinary operational work. A support engineer can compare the returned timezone with an outage timestamp. A security analyst can see whether a source belongs to a residential ISP, hosting provider, or public infrastructure network. A site owner can paste a hostname directly instead of performing separate DNS and geolocation checks by hand.
The main caution is that precision-looking output can be misleading. A city line or map point may describe provider infrastructure rather than the user you have in mind. Hostname-based lookups are also snapshots, because the package resolves only one current address before it asks the geolocation provider for details.
Use the result as coarse network evidence. It is well suited to triage, annotation, and first-pass review, but it should not be treated as proof of street-level identity or exact user location.
If you already know the public address you care about, paste the address itself into IP Address. That avoids the extra hostname-resolution step and gives you the cleanest first pass. If all you have is a domain or URL, paste the full value anyway. The package will strip it down to the host, attempt an A lookup first, and use AAAA only if no A answer is found.
The most practical reading order is IP, Type, Country, City, Timezone, ISP, ASN, and then Reverse DNS. That sequence tells you what was actually looked up, where the address appears to be routed, and who is likely operating it. The map is best treated as a visual aid after those fields, not before them.
Use my IP is only for checking your own current public address. It first asks a public-IP service for the address visible to the wider Internet, then runs the normal lookup path on that value. This is useful for a quick "what am I presenting as?" check, but it does not reveal a private router address such as 192.168.1.20.
Host.ASN does, believe the network context first. A cloud-hosting ASN plus a neat city line usually means infrastructure geography, not end-user geography.Reverse DNS is empty, the address may still be valid. PTR records are optional and many addresses publish none.This workflow is strongest for public endpoints. It is a weak fit for private, reserved, or local-only names, because those targets cannot be turned into usable public geolocation records by the shipped lookup path.
The package follows a fixed pipeline from input text to displayed fields. First it decides whether the input already looks like IPv4 or IPv6. If not, it extracts a hostname from the pasted domain or URL, removes trailing dots, and resolves that hostname through public DNS-over-HTTPS endpoints. The code asks Google first, then Cloudflare, and prefers A answers before falling back to AAAA.
Once it has one public address, the slug requests geolocation data for that address from ipinfo.io, using the site's CORS helper first and a direct request as fallback. The response is normalized into the fields shown by the interface: IP, address family, region, country, city, postal code, latitude, longitude, timezone, ISP, ASN, and organization. The browser then formats a local-time badge from the returned IANA timezone identifier.
Reverse DNS is a second branch, not part of the main geolocation response. For IPv4, the package reverses the four octets and appends in-addr.arpa. For IPv6, it expands the address to eight hextets, pads each one, reverses the 32 hexadecimal nibbles, and appends ip6.arpa. It then requests a PTR record through the same public DNS-over-HTTPS providers. If no PTR answer exists, the field stays blank.
The map tab is intentionally simple. When numeric coordinates are present, the package places a single marker, fits the viewport around it, and provides quick links to OpenStreetMap and Google Maps. The map is therefore a display of the returned coordinates, not a second independent location engine.
Two limits are easy to miss. First, hostname lookups are snapshots because only one resolved address is carried forward into enrichment, even if the hostname serves multiple addresses through load balancing, anycast, or CDN routing. Second, this is not a local-only lookup. DNS resolution, public-IP detection, geolocation, PTR lookup, and map tiles all depend on live external network services.
| Stage | What the package does | What you see |
|---|---|---|
| Input classification | Checks whether the text already matches a public-looking IP pattern | Direct IPs skip hostname extraction |
| Host extraction | Pulls the host from a domain or URL and removes trailing punctuation | Host can be preserved in the summary |
| DNS resolution | Queries public DoH providers, trying A before AAAA | The lookup target becomes one resolved public IP |
| Provider enrichment | Requests geolocation and network-owner fields for that IP | Location, timezone, ISP, ASN, and organization populate |
| PTR lookup | Builds a reverse-DNS name and asks for a PTR record | Reverse DNS appears when published |
| Map render and exports | Plots one marker and enables coordinate, table, and JSON export paths | Map and JSON tabs become actionable |
The result is strongest when you read location and routing together. Country, city, and coordinates provide context, but ASN, organization, and reverse DNS often tell you more about what kind of endpoint you are actually looking at.
IP Address, or choose Use my IP for your own current public-facing address.Lookup. If the input is a hostname, the package resolves one current address before enrichment begins.Location Summary from top to bottom, starting with IP, Type, Country, City, Timezone, ISP, and ASN.Host so you know the result came from host resolution rather than direct-IP entry.Reverse DNS when you want an infrastructure hint, but do not treat a blank field as failure.Map only after the summary makes sense. Use it to copy coordinates or open external map links, not as a substitute for the routing fields.JSON when you need the normalized payload, or export the summary table as CSV or DOCX for documentation.If the tool reports Could not resolve domain to an IP. or Lookup failed., switch to a known public target. Private, reserved, or non-resolving names are outside the capabilities of this slug.
A useful result usually has internal agreement. If country, timezone, ASN, and the broad business context all line up, the lookup is doing its job as a first-pass classifier. That is often enough for support triage, access-review notes, or a quick fraud-screening clue.
A mismatch tells you more than a neat map pin does. A city might look precise, but if the ASN belongs to a major cloud provider, public resolver, mobile carrier, or CDN, the geographic point may reflect provider infrastructure. Likewise, a VPN or foreign resolver can make the apparent country differ from the user's actual location.
Coordinates deserve extra restraint. The tool treats them as provider-supplied latitude and longitude, then simply places a marker. They are helpful for rough orientation and cross-checking, but they are not evidence of a household, floor, or exact user device. PTR results also need caution because they often describe routers, gateways, or branded service names rather than the endpoint you actually care about.
The safest interpretation habit is to carry four fields together: IP, ASN, Timezone, and Host when present. Those fields travel better across tickets and reviews than a copied city name or map point alone.
Enter 8.8.8.8. The package treats it as a direct IPv4 address, enriches it, and can return a result centered on Mountain View, California with ASN = AS15169, organization details for Google, an America/Los_Angeles timezone, and a PTR name such as dns.google when available. That is useful network context, but it still describes public infrastructure rather than a person's device.
Enter https://dns.google/. The tool extracts dns.google, resolves one current address, preserves the hostname in Host, and then geolocates the resolved IP. If the service later resolves somewhere else, the old result does not automatically remain valid. The lookup always reflects the address chosen at that moment.
Enter 192.168.1.10 or a local-only name that does not resolve publicly. The bundle cannot turn that into a usable public geolocation record, so the summary remains empty and the error path is triggered. That is expected behavior, not a sign that the parser or map is broken.
A public IPv4 address, a public IPv6 address, a plain domain, or a full URL. The hostname is extracted automatically when needed.
Because the geolocation provider works on an address, not on the URL string itself. The original hostname is preserved in Host when the lookup began from a domain or URL.
Yes, but not at the same time for one hostname. It tries A records first and only falls back to AAAA when no A answer is returned.
PTR records are optional. Many valid public addresses publish none, and others publish names that describe provider infrastructure rather than the service or person you expected.
No. It asks a public-IP service which address your browser is presenting externally, then geolocates that public-facing address.
No. The map only visualizes the returned coordinates. Those coordinates are approximate network-location data and may reflect infrastructure rather than the end user.
Common causes include private or reserved addresses, domains that do not resolve to usable public records, provider timeouts, or a geolocation response with no public IP result.
No. The slug depends on live DNS resolution, public-IP detection, geolocation, PTR lookup, and map services. Use it with the understanding that the target is sent to external network providers during lookup.
America/Los_Angeles that the browser can use to format local time.