How do you find a website's IP address?
You resolve its hostname through DNS: a resolver looks up the name's A records and gets back one or more IPv4 addresses. This tool runs that lookup on our server and prints every IPv4 address the hostname resolves to, one per line. If the name is an alias (a CNAME), the resolver follows it and you get the addresses at the end of the chain.
Example
For a hostname served by two web servers, the output is simply:
192.0.2.10
192.0.2.11
(These are addresses from 192.0.2.0/24, a block reserved for documentation by RFC 5737, standing in for real results, which change.) The order isn't meaningful. Many sites use several A records for load distribution, and resolvers may rotate them between queries.
If nothing comes back, you'll see Could not resolve "name" to an IP address. That usually means the name has no A record, the domain doesn't exist, or it's IPv6-only.
What counts as a valid hostname here
The input is checked before any lookup. Each dot-separated label can be 1 to 63 letters, digits, hyphens or underscores, can't start or end with a hyphen, and there must be at least two labels. A single trailing dot, as in a fully qualified example.com., is dropped first.
| Input | Result |
|---|---|
www.example.com |
Looked up |
example.co.uk |
Looked up |
https://example.com |
Rejected: remove the scheme |
example.com/page |
Rejected: remove the path |
example.com. |
Looked up as example.com |
localhost |
Rejected: needs at least one dot |
my_host.example.com |
Looked up (underscores are legal in DNS names) |
bücher.example |
Looked up as xn--bcher-kva.example |
Internationalised domain names are stored in DNS in their ASCII "xn--" form (RFC 5891), so the tool converts a Unicode spelling to that form before querying.
How the lookup works
The A record type is defined in RFC 1035, the core DNS specification: it holds a single 32-bit IPv4 address. Our server hands the name to its configured recursive resolver, which walks the DNS hierarchy (or answers from cache) and returns all A records it finds. Because resolvers cache answers for each record's time-to-live, a change you made a few minutes ago may not show up yet.
This tool only asks for IPv4. IPv6 addresses live in AAAA records, defined separately in RFC 3596; look those up with the DNS lookup tool, which also covers MX, TXT, NS and CNAME.
Practical uses
- Confirming a DNS change. After pointing a domain at a new host, check that the new IP appears here. If you still see the old one, the old record is probably cached somewhere; wait for its TTL to expire.
- Finding which host or CDN serves a site. Resolve the name here, then reverse it with the IP to hostname tool. A PTR name often reveals the provider.
- Verifying a crawler. Google's procedure for verifying Googlebot ends with a forward lookup: take the hostname from the reverse lookup, resolve it, and check it matches the original IP. That forward step is what this tool does.
- Building allowlists. Firewalls and API allowlists usually need IPs, not names. Resolve the partner's hostname, but remember IPs behind a CDN can change without notice.
- Comparing environments. Check that
wwwand the bare domain point where you expect, before a migration.
Things this lookup can't tell you
An IP address isn't a website. One address on shared hosting or a CDN can serve thousands of unrelated domains, so visiting the IP directly often shows a default page or an error. And because CDNs answer by location, the address here is the one nearest our server, not necessarily the one your visitors reach.
The result also says nothing about whether the site is up. A hostname can resolve perfectly while the server behind it is down; the redirect checker makes an actual HTTP request and shows the status code.
Last updated