How to Find a Website's IP Address (and What It Reveals)

Every website lives at an IP address, and finding it takes seconds once you know how. More usefully, that address is a doorway to real information: who hosts the site, roughly where its server sits, and which network it belongs to. This guide covers several quick ways to find any site's IP — from a one-line ping to your browser's own tools — and explains what the address actually reveals, plus the important caveat that a CDN changes the answer.

It is a focused companion to how to find out where a website is hosted; the IP is the first step in that larger trace.

Why find a website's IP address?

There are plenty of legitimate reasons. Developers and sysadmins check which server a domain resolves to when debugging DNS or deploying changes. Security and abuse research starts from the IP to identify a host to contact. Competitive and due-diligence work uses the IP to learn who a site is hosted with and where. And anyone curious about a site's infrastructure begins here, because almost every other infrastructure fact — the host, the location, the network — follows from the address. It is the atomic unit of "where does this site actually live?"

Method 1: Ping the domain

The simplest method works on every operating system. Open a terminal or command prompt and type ping example.com. Ping resolves the domain to its IP address and shows it in the output, usually in the first line, before sending its test packets. Even if the server does not respond to ping (some block it), the resolution step still prints the IP. It is the fastest possible check and requires nothing but a terminal you already have.

Method 2: Use nslookup or dig

For a cleaner, more detailed answer, use a DNS query tool. nslookup example.com (available on Windows, macOS and Linux) returns the domain's address records. On macOS and Linux, dig example.com is more powerful: dig +short example.com A prints the IPv4 address and dig +short example.com AAAA prints the IPv6 address. These tools query DNS directly, so they show exactly what the domain resolves to, and dig in particular lets you inspect other record types in the same session.

Method 3: Read the Remote Address in DevTools

Your browser already knows the IP it connected to. Open DevTools (F12), go to the Network tab, reload the page, click the first (document) request, and look in the Headers for the Remote Address — that is the IP your browser actually connected to for that resource. This is a useful cross-check because it reflects the live connection, including whichever CDN edge served you, rather than a separate DNS query that might resolve differently.

Method 4: Online IP-lookup tools

If you prefer not to touch a terminal, many websites perform a DNS lookup for you: paste the domain and they return the IP, often alongside the host, location and other DNS records. Broader site-analysis tools — StackOptic among them — resolve the IP as part of a wider report that also identifies the hosting provider, CDN and the rest of the stack, which saves stringing several lookups together by hand.

Method 5: Trace the route

traceroute example.com (or tracert on Windows) shows the network path packets take to reach the site, ending at the destination IP. It is more than you need just to find an address, but it is informative when you are diagnosing connectivity or want to see the networks between you and the server. The final hop is the IP serving the site (or the CDN edge nearest you).

What an IP address reveals

The address itself is just numbers; its value is what you can look up from it. A WHOIS or RDAP lookup on the IP returns the organisation that owns the address block and its autonomous system number (ASN) — which usually names the hosting provider or cloud directly (AWS, Google Cloud, Microsoft Azure, Hetzner, DigitalOcean and so on). Reverse DNS (the IP's PTR record) often confirms it with a descriptive hostname. And IP geolocation gives an approximate physical location for the responding server. From a single address, in other words, you can usually answer "who hosts this and roughly where?" — the core of any infrastructure read.

IPv4 vs IPv6

You may get two different-looking addresses for the same site. IPv4 addresses look like 93.184.216.34; IPv6 addresses are longer and use hexadecimal, like 2606:2800:220:1:248:1893:25c8:1946. A modern site commonly has both, published as A (IPv4) and AAAA (IPv6) records, and your connection may use either. Neither is more "correct" — they are two addressing systems running in parallel, and a complete lookup checks for both.

The CDN caveat: edge, not origin

Here is the crucial nuance. If a site sits behind a reverse-proxy CDN such as Cloudflare, Fastly or Amazon CloudFront, the IP you find belongs to the CDN's edge network, not the site's origin server. DNS deliberately points at the CDN, and the origin IP is hidden as a security measure. So an IP lookup on a Cloudflare-fronted site returns Cloudflare — which is the honest description of how the site is served, not a detection failure. If you specifically need the origin, see the discussion in how to find out where a website is hosted; often it simply cannot be found, by design.

Why you might get several different IPs

Beyond IPv4/IPv6, a single domain can resolve to multiple addresses for load balancing (spreading traffic across servers) or via anycast, where the same advertised address routes to whichever of many physical locations is nearest you. This is why two people in different countries can get different IPs for the same site, and why repeated lookups sometimes vary. It is a sign of scale and resilience, not inconsistency.

A worked example

Suppose you want to know who hosts a competitor at shop.example. You run dig +short shop.example A and get a single IPv4 address. A WHOIS lookup on that IP returns an organisation name and an ASN belonging to a well-known cloud provider, and reverse DNS shows a hostname ending in that provider's domain — so you now seem to know the cloud they run on. But then you notice the response headers include cf-ray, and a second look shows the IP actually belongs to Cloudflare. That tells the real story: the site is fronted by Cloudflare, and the cloud you first inferred would only be the origin if it leaked through a non-proxied record. In a couple of minutes, with nothing but a terminal and DevTools, you have gone from a bare domain to a clear picture of the edge and a sensible hypothesis about the origin — which is the typical shape of an IP investigation, and a good illustration of why one signal is never enough.

Reading geolocation results with care

IP geolocation is the part people most often over-trust. The city a lookup returns is where the responding address is registered, which behind a CDN is the nearest edge node — not where the business or its origin server sits. Even for a directly connected server, geolocation databases can lag a physical move by months, and they frequently resolve only to a data-centre region rather than a precise spot. So treat a geolocation result as a rough hint about a provider's region, useful for a quick sanity check, and never as proof of where a company or its servers physically are. If location genuinely matters for your purpose, corroborate it with the IP owner from WHOIS, the hosting region, and any non-proxied records before you rely on it, because the headline city is the least reliable thing an IP lookup gives you.

How accurate is an IP lookup?

The address itself is exact — it is what your machine resolves and connects to. The interpretation has caveats: the owner is reliable via WHOIS/RDAP, but geolocation is approximate (it reflects the registry record, not necessarily the server's true location), and a CDN masks the origin. Treat the IP as ground truth for "what am I connecting to" and the derived host/location as a strong but caveated inference. As always, corroborate with a second signal before drawing firm conclusions.

The quick workflow

1. Ping or nslookup/dig the domain for the IP (check both A and AAAA).
2. Confirm in DevTools via the Remote Address if you want the live connection.
3. WHOIS/RDAP the IP for the owning organisation and ASN.
4. Note whether it is a CDN — if so, you have the edge, not the origin.
5. Cross-check the owner against the response headers before concluding.

Go deeper

• The full infrastructure trace: how to find out where a website is hosted.
• Is that IP a CDN? How to tell if a website uses Cloudflare.
• The big picture: how to find out what a website is built with.

Want the IP, host, CDN and full stack in one click? Analyse any site with StackOptic — free, no sign-up.