Website hosting checker

Website hosting checker is a free tool that resolves a host on the server and reports the ISP, organization, approximate network location, and time zone associated with the resolved address.

Why does a hosting lookup begin with DNS?

A hosting lookup begins with DNS because a website name must resolve to an IP address before its network provider can be identified. This tool uses PHP's gethostbyname function, which performs an IPv4 hostname lookup, after processing the submitted value with parse_url.

The resulting address is associated with network and location data. That information can indicate the ISP or organization operating the visible network endpoint. It does not necessarily identify the company that sold the hosting plan.

A CDN, reverse proxy, security service, or managed platform may sit between visitors and the origin server. In those cases, the result can describe the intermediary's network rather than the origin host. The checker also does not request a web page, inspect application files, or log in to the hosting account.

Which result field can answer your question?

Each result field describes a different part of the network associated with the resolved host.

Latitude and longitude are not a street address for the physical server. IP location data may point to a city, regional network facility, provider office, or registration location. It should not be used to identify a building or a person.

The listed result fields do not include the DNS TTL, authoritative nameservers, HTTP response, certificate details, or an explicit IP address field. You may need a dedicated DNS, HTTP, or TLS check when the problem depends on one of those values.

Three diagnostic situations

A hosting result is most useful when you compare it with the provider or network you expect to see.

• A migrated website still reaches the former host. Check the hostname that visitors use. If Organization or ISP still points to the previous network, a cached or unchanged DNS record may be involved.
• The zone apex works, but the www version fails. Run separate checks for values such as example.com and www.example.com. Those names can have different DNS records and can route through different providers.
• A certificate warning appeared after a hosting change. The hosting result can show the network associated with the resolved address, but it cannot inspect the certificate. If the host points to the expected infrastructure, use a certificate or HTTPS diagnostic next.

For a concrete workflow, submit store.example.com in Host. Suppose the organization shown belongs to a CDN rather than the hosting company named on your invoice. That result suggests the resolved address is associated with the CDN's network, but it does not reveal the protected origin server.

Email delivery needs a different starting point. A check of mail.example.com can describe that hostname's visible network, but it does not examine the domain's MX records or confirm that an SMTP server accepts mail.

Why can a recent DNS change still appear wrong?

A recent DNS change can appear wrong because recursive DNS resolvers cache earlier answers until their time-to-live period expires. Browsers, operating systems, routers, and provider resolvers may also retain information for a while.

DNS changes are often described as "propagation," although records are not normally pushed to every resolver at once. Each resolver generally fetches the new answer when a subsequent query requires it after its cached copy expires, although some may serve stale data under defined conditions. Two checks made from different networks can therefore disagree temporarily without either network being broken.

This checker performs its work on the server, so its DNS view may differ from the view on your laptop, office network, or mobile connection. If a migration is recent, compare results over time and query the authoritative DNS records separately. The Google Cache Checker addresses cached search content, not DNS resolver caching, so it answers a different question.

What should you enter in the Host field?

Enter the specific hostname involved in the problem, preferably without a page path, query parameters, spaces, or surrounding punctuation. A hostname such as api.example.com gives a clearer target than a copied address containing an entire page path.

Numbers and hyphens are valid in many hostname labels, subject to DNS naming rules. Underscores are used in some DNS record names but are not valid in ordinary hostnames. Accented and non-Latin domain names are represented in DNS through Internationalized Domain Names and Punycode. If a Unicode form does not resolve, try its ASCII Punycode form.

An empty value cannot identify a host. Very long names must also stay within DNS limits, including a maximum of 63 octets per wire-format label and 255 octets for the complete wire-format name, including length octets and the root label. The usual presentation-format maximum is 253 characters without a trailing dot. This tool does not promise to correct malformed input, so remove copied punctuation and verify spelling before treating a failed lookup as a hosting outage.

The input travels to the server over HTTPS because the lookup is performed there. The submitted Host value is not stored. Avoid submitting internal hostnames if revealing the name itself would be sensitive.

Frequently asked questions

Can this checker find a server hidden behind a CDN?

No. DNS commonly returns the CDN or proxy endpoint presented to the public, so the associated fields usually describe that visible network. Revealing an origin requires other records or account-level information and may be intentionally prevented.

Does the checker test whether a website is online?

No. The underlying check resolves a hostname, but it does not make an HTTP request or confirm that a page returns a successful status. An HTTP/2 Checker can provide protocol information when the host resolves but browser access still fails.

Why does the reported time zone differ from the website's business hours?

The time zone belongs to the approximate network location data, not to the site owner or intended audience. A U.S. business can use infrastructure registered in another state or country, and a distributed service can route traffic through several regions.

Can I check a private name such as localhost or an office server?

A server-side lookup uses the tool server's DNS environment, not your computer's hosts file or private office DNS. Names available only inside your network will generally have no useful public result. Test those names with DNS tools inside the network instead.

Is it safe to use the coordinates as evidence of data residency?

No. IP geolocation is approximate and does not prove where files, backups, or customer records are stored. Data residency should be verified through provider documentation, contracts, and account configuration.

Final checks

Check the exact hostname that is failing, compare ISP and Organization with the expected network, and treat the coordinates as approximate. After a DNS change, allow cached answers to expire before drawing a firm conclusion. If the host resolves to the expected provider but the site still fails, continue with HTTP, certificate, and authoritative DNS checks.