How to Find the IP Address of a Website (Ping, nslookup, dig)

The fastest way to find a website's IP address: open a terminal (Command Prompt on Windows, Terminal on Mac) and type nslookup example.com or ping example.com. The IP shows up in the first lines of output. Nothing to install, either: both commands ship with every operating system.

That answers the question in ten seconds. The interesting part is what comes next: why you and a friend can get different IPs for the same site, why the address you found often belongs to Cloudflare rather than the website itself, and what you can actually learn from it. All of that is below.

The Three Command-Line Methods

Under the hood, all three commands do the same thing: they ask the DNS (the internet's phone book, which maps names like example.com to numeric addresses) for the site's records. Where they differ is in how much they show you, and how reliably they work.

1. ping: quick, but not built for this

$ ping example.com
PING example.com (93.184.215.14): 56 data bytes
64 bytes from 93.184.215.14: icmp_seq=0 ttl=56 time=12.4 ms

The IP sits in parentheses on the first line, because ping resolves the name before sending anything. On Windows, ping sends four packets and stops; on macOS and Linux it runs forever, so press Ctrl + C to stop it, or use ping -c 4 example.com to cap it at four.

The catch: ping measures reachability using a protocol called ICMP, and plenty of servers block ICMP entirely. If you see "Request timeout" on every line, that does not mean the site is down or the IP is wrong. The DNS resolution on the first line already succeeded. The IP is valid; the server just refuses to answer pings.

2. nslookup: the standard, works everywhere

$ nslookup example.com
Server:   192.168.1.1
Address:  192.168.1.1#53

Non-authoritative answer:
Name:     example.com
Address:  93.184.215.14

This is the purpose-built tool, preinstalled on Windows, macOS, and Linux alike, with identical syntax on all three. The first block tells you which DNS server answered (here, the home router at 192.168.1.1); the second block is the answer you want. "Non-authoritative" just means the response came from a cache rather than the site's own DNS server. For finding an IP, that distinction doesn't matter.

If a site has several addresses, nslookup lists them all. That's normal, not an error. More on why in a moment.

3. dig: the most precise (developers' choice)

$ dig example.com +short
93.184.215.14

$ dig example.com AAAA +short
2606:2800:21f:cb07:6820:80da:af6b:8b2c

dig gives you exactly what you ask for and nothing else. The +short flag strips the output down to the bare answer, which makes it perfect for scripts. Asking for the AAAA record (the second command above) returns the site's IPv6 address, something ping and basic nslookup won't show you by default. Run dig without +short and it also reveals the record's TTL, the number of seconds the answer may be cached. That detail is gold when you're debugging DNS changes.

One platform note: dig comes preinstalled on macOS and Linux, but not on Windows. Windows users can stick with nslookup, install dig via the BIND tools, or run dig inside WSL.

Analyze the IP You Found

A bare number like 93.184.215.14 tells you nothing by itself. To make it talk, paste it into the lookup field on our homepage: you'll see which hosting company or network operates it (the ASN), which country the server sits in, and whether it's a datacenter, residential, or mobile address. For a website, "datacenter" is the expected answer. The ASN is often the single most informative field, because it names the actual infrastructure provider: Amazon, Cloudflare, OVH, Hetzner, and so on.

This is the quickest way to answer questions like "is this site behind Cloudflare?" or "is this suspicious link hosted on a cheap bulletproof host?" That's context a DNS lookup alone can't give you.

Why the IP Changes Every Time

Run the same lookup twice and you may get two different answers. Nothing is broken. A modern website simply doesn't have one address. Three mechanisms are at play:

DNS round-robin. A domain can publish several A records, and DNS servers rotate the order with each response. Each visitor lands on a different server from the pool. It's the oldest and simplest form of load balancing.
CDNs answer by location. Content delivery networks return different IPs depending on where you ask from. A lookup from Paris and a lookup from Tokyo get different answers, both correct, each pointing to a nearby server.
Anycast. The reverse trick: a single IP is announced from dozens of locations at once, and the internet's routing delivers your packets to the nearest one. The IP looks stable, but the machine behind it depends on where you are.

So treat any IP you find as an address for the site, valid from your location at this moment, not the address.

The CDN Reality Check

Here's the part most tutorials skip: for a large share of the web, the IP you just found doesn't belong to the website at all. It belongs to a CDN or reverse proxy (Cloudflare, Akamai, Fastly, CloudFront) that sits in front of the real server, caches its content, and absorbs attacks. The DNS record points at the proxy; the origin server's IP is deliberately never published.

This is by design, and a lookup can't "get around" it. The origin only accepts traffic from the CDN, and hiding its address is precisely how the site shields itself from direct attacks. If your result resolves to an ASN named Cloudflare or Akamai, you've found the site's front door. For any practical purpose (checking reachability, debugging DNS, allowlisting), that front door is exactly the address that matters anyway, because it's the one your browser actually connects to.

IPv4 vs IPv6 Records: A and AAAA

DNS stores the two kinds of addresses in two kinds of records. An A record holds an IPv4 address (93.184.215.14); an AAAA record, pronounced "quad-A", holds an IPv6 address (2606:2800:21f:cb07:…). The name is a small joke from the standards authors: an IPv6 address is four times longer than an IPv4 one, so the record got four A's.

Most tools default to A records, which is why you usually see only the IPv4 address. To check whether a site is reachable over IPv6, ask explicitly: dig example.com AAAA +short or nslookup -type=AAAA example.com. No answer means the site is IPv4-only, which is still common today. If the two protocols and why they coexist are new to you, IPv4 vs IPv6 covers the whole story.

What You Can (and Can't) Learn from a Website's IP

What you can learn: the hosting provider or network operator (via the ASN and WHOIS records, which are public by design), the rough location of the serving infrastructure, and whether the site sits behind a CDN. Useful stuff for debugging, security triage, or plain curiosity.

What you cannot learn: who personally runs the website. The IP identifies the infrastructure, not its tenant. Millions of sites share IPs on big hosting platforms, and WHOIS for the address block names Amazon or OVH, not the customer renting a slice of it. Take the geolocation with a grain of salt too: it points at a datacenter, which may sit nowhere near the company behind the site. A thoroughly French website served from Frankfurt is unremarkable. IP geolocation has the same limits for servers as it does for people, explained in why IP location is often wrong.

A note on legality, since the question comes up: DNS is a public directory, and querying it is how the internet works. Your browser performs the exact same lookup every time you visit a site. Running nslookup or dig on any domain is perfectly legal and undetectable by the website. (Aggressively port-scanning the server you found is a different activity with different rules, but nothing in this guide goes near that.)

Key Takeaways

Fastest method: nslookup example.com, which works unchanged on Windows, macOS, and Linux. Most precise: dig example.com +short (macOS/Linux).
ping shows the IP too, but timeouts only mean ICMP is blocked. The resolved address on the first line is still valid.
A modern site has many IPs: round-robin DNS, CDNs, and anycast mean your answer depends on when and where you ask.
Behind a CDN, the IP you find is the proxy's (Cloudflare, Akamai…), not the origin server's. That's intentional, not a flaw in your lookup.
An IP reveals the hosting provider, not the website's owner. Paste it into our homepage lookup to see the ASN, country, and connection type.

Common Questions

Why do I get a different IP than my friend for the same website?

Because you're asking different DNS servers from different places. CDNs deliberately hand out the address of the server closest to whoever asks, and round-robin DNS rotates through a pool of addresses on every response. Both of you received a correct answer for your respective locations. That's expected behavior for any site of meaningful size, not a sign that one of you is being deceived.

Can I find who owns a website from its IP?

Usually not. A WHOIS query on the IP names the organization that controls the address block, which is almost always a hosting company or CDN, not the site's operator. Thousands of unrelated websites can share one IP on the same platform. If you need to identify who runs a site, the domain's WHOIS record, its legal or imprint page, and its TLS certificate are far better leads than the IP.

Does a website see that I looked up its IP?

No. nslookup, dig, and the resolution step of ping query the DNS system (typically your router's or ISP's resolver), and the website's server is never contacted. The lookup is invisible to the site. The exception is ping itself: once the name is resolved, it does send packets to the server, which could in principle be logged. A pure DNS lookup leaves no trace anywhere the website can see.