How to find a website's IP address

Every website has an IP address. The name — github.com, bbc.co.uk, whatever — is a human-readable label that gets translated to numbers before any actual connection happens. When you type a URL into your browser, the very first thing your computer does is ask a DNS resolver: "what IP address does this name point to?" Only then does it open a connection to that address.

Most of the time this happens invisibly in under a millisecond, and there's no reason to look at the result. But there are situations where knowing the raw IP matters — and finding it takes about five seconds once you know where to look.

Why you'd want to know

A few practical situations where the IP actually matters:

• Debugging a connection problem. If you can reach an IP directly but not the domain name, the fault is in DNS resolution, not the server. If neither works, it's the server or the network path to it. Knowing which layer is broken saves time.
• Confirming a DNS change has propagated. After moving a site to a new server, you want to verify the name now resolves to the new IP, not the old one. DNS changes can take time to spread through caches worldwide, and the IP is how you tell.
• Checking whether two hostnames point to the same server. If www.example.com and api.example.com resolve to the same IP, they're likely served from the same machine or the same CDN edge node.
• Network testing and firewall rules. Some infrastructure setups require allowlisting specific IPs rather than hostnames, so you need the actual address to write the rule.
• Understanding who's serving a site. The IP block can tell you whether a site is on AWS, Cloudflare, its own data centre — useful context for security research, due diligence, or plain curiosity.

The easy way — a DNS lookup tool

The fastest method is a dedicated DNS lookup tool. Our DNS Records tool lets you type any hostname and see the records it resolves to: A records for IPv4, AAAA records for IPv6, CNAME chains, MX, TXT — the full picture.

Type github.com and you'll see something like 140.82.112.3 in the A record. Type www.google.com and you might see eight or more different addresses — Google returns a rotating set to distribute load across its servers, and different resolvers get different answers.

The A record is the direct IPv4 address. An AAAA record is the IPv6 equivalent — the same destination, reachable over IPv6. If a hostname has a CNAME record, that's an alias pointing to another name, which then resolves to an IP. The tool follows the full chain and shows you each step, which is useful when a hostname resolves through several aliases before reaching an actual address.

The TTL (time-to-live) value shown alongside each record tells you how long DNS resolvers are allowed to cache the answer. A TTL of 60 seconds means the record expires from caches in a minute and resolvers have to ask again. A short TTL often signals that the operator expects to make changes soon — common during migrations.

Browser DevTools

If you're already looking at a site in your browser, DevTools gives you the IP without leaving the page.

In Chrome or Edge: press F12 (or Ctrl+Shift+I on Windows/Linux, Cmd+Option+I on Mac) to open DevTools, then switch to the Network tab. Reload the page. Click on any request in the list — the main document is usually at the top. In the Headers panel on the right, look for a Remote Address field. That's the IP and port the browser actually connected to for that specific request.

In Firefox: same shortcut, same Network tab. The field is labeled Remote IP in the request details.

The DevTools method has an advantage over a plain DNS lookup: it shows you the IP your browser used for this particular connection, not just what DNS returned. On a CDN-fronted site those may differ if the browser is holding a cached record from an earlier lookup. It also shows you the port — if a site is running on a non-standard port, you'll see that here too.

There's a quicker path in newer Chrome versions: click the padlock icon in the address bar, then Connection is secure, then Certificate. The connection details view shows the server IP alongside the TLS certificate information.

Command line: dig, nslookup, host

If you spend time in a terminal, the command-line DNS tools give you more control and are easy to script.

dig is the most informative of the three. On Linux and macOS it's typically installed by default. On Windows you can get it via the BIND tools package, or use WSL.

dig github.com

The output shows the full DNS response: the question you asked, the answer section with each record, and statistics at the bottom — including which resolver answered and how long it took. An A record in the answer section looks like:

github.com.   60   IN   A   140.82.112.3

To query a specific DNS server instead of your system default, add @server:

dig @8.8.8.8 github.com

That sends the query to Google's public resolver directly. If your default resolver and 8.8.8.8 return different IPs for the same hostname, something interesting is happening — your ISP may be intercepting or modifying DNS responses, or you're catching a change mid-propagation.

To ask specifically for IPv6 addresses, query the AAAA record type:

dig AAAA github.com

nslookup is older and ships everywhere, including Windows by default:

nslookup github.com

Less detail than dig, but it works. For reverse lookups — turning an IP back into a hostname — nslookup 140.82.112.3 queries the PTR record for that address. The hostname in the PTR record is set by whoever owns the IP block, which is usually the hosting company rather than the site operator.

host has the simplest syntax:

host github.com
host -t AAAA github.com

Returns addresses concisely, one per line. Good for piping into shell scripts when you just need the raw output.

All three tools do the same thing: send a DNS query and display the response. The difference is how much detail they expose and what flags they support. For most purposes, dig is the one worth learning.

ping — a quick check with caveats

ping is often the first thing people reach for, and it does resolve the hostname first:

ping github.com

The first line of output shows the IP it resolved to:

PING github.com (140.82.112.3): 56 data bytes

So ping works as a quick way to confirm what address a hostname resolves to. But relying on it has two problems.

First, ping may simply fail even when the site is up. Many servers — especially those behind Cloudflare and other CDNs — drop ICMP echo requests entirely. If ping github.com returns "Request timeout" or "100% packet loss", that tells you nothing about whether the site is actually reachable. ICMP is being filtered, not the HTTP traffic.

Second, the IP ping uses is just the address it got from DNS for that particular request. On a large CDN, the address you see depends on your location, your resolver, and the routing table at that moment. Another machine on a different network may see a completely different IP for the same hostname, and both answers are correct — they point to different edge nodes serving the same content.

Use ping for a fast sanity check. Don't read too much into timeouts, and don't assume the IP you see is the only one that matters.

The CDN reality

For a small site running on a single server, the IP you look up is the actual machine. For sites using a content delivery network, the picture is more layered — and the IP you get from DNS may not mean what you think it does.

Services like Cloudflare, Akamai, and AWS CloudFront operate globally distributed networks with hundreds of locations. When you resolve www.amazon.com, the IP you get isn't "Amazon's server" — it's the nearest CloudFront edge node to your DNS resolver. Someone in Tokyo resolves the same hostname and gets a different IP pointing to a Tokyo edge. Both are correct. The origin server — the actual machine where Amazon's application runs — is further back and often not directly reachable from the public internet at all.

This changes what "the IP" means in a few ways:

• You can't reach the origin server directly. The IP from DNS is an edge node. The real backend may sit behind a private network with no public address.
• The IP can change frequently. CDNs rotate IPs, sometimes on every DNS TTL, sometimes faster under load. The address you looked up five minutes ago may not be the one serving the site now.
• Geolocation of the IP reflects the edge, not the company. If you look up the IP of a Cloudflare-proxied site and see "San Jose, CA", that's a Cloudflare data centre near your resolver, not the site owner's location.

None of this makes IP lookups useless — it changes what the result means. For a CDN-fronted site, the IP tells you which edge network is handling the traffic, what ASN owns the block, and roughly which region is serving you. You can paste any IP into our IP lookup tool to see who owns the range and get the full geolocation and ASN data. To understand your own IP — the one websites see when you visit them — the What Is My IP Address guide covers that in detail.