Choose IP tools by the question you need to answer
IP tools are most useful when you begin with a specific question. Do you need the public address used by your browser, the records published for a domain, the network registered for an address, or the boundaries of a subnet? Those tasks need different operations. The IP tools above keep the operations separate so a familiar-looking result does not accidentally answer the wrong question.
If you need your own current address, use the homepage. It observes the source of the browser connection or uses a disclosed browser-side endpoint when a trusted direct observation is unavailable. Other IP tools accept an address you type. A typed lookup can be useful for a log entry or support report, but it does not establish that your own device currently uses that address.
IP tools for address context and registration
Use IP lookup to classify an address and retrieve supported network registration fields for public space. Private and special-use ranges are handled separately because they do not identify one globally unique internet subscriber. IP tools should not turn 192.168.1.1 into an invented public owner: that private address can appear in countless independent local networks.
Use IP WHOIS lookup when the registration task is your main focus. It uses RDAP and links the responsible regional registry response. The IP tools report network names, ranges, handles, and available registration attributes. They do not identify a person behind a shared address or convert a registration country into precise physical location. Read the source alongside the field name.
For a domain's registration, choose domain WHOIS lookup. These IP tools keep name registrations separate from address allocations. The domain report shows the selected registry, registrar information, events, statuses, nameservers and privacy notices when returned. It does not reconstruct hidden contacts or guarantee that an apparently missing name can be purchased.
IP tools for autonomous systems
Use ASN lookup to inspect the origin networks observed for a public address or the overview of a particular number. These IP tools preserve multiple returned origins and distinguish collected routing evidence from address registration. A negative visibility field is not a direct outage test, and a network name is not the subscriber's identity. Keep the queried resource and source time with the result when comparing IP tools or preparing a support report.
IP tools for DNS and reverse DNS
Use DNS lookup when you have a domain and need a particular record type. A and AAAA describe published address destinations; MX concerns mail routing; TXT supports several text-based uses. IP tools that query DNS should preserve the response code, record type, TTL, resolver, and observation time. A blank answer table without that context can easily be misunderstood.
Use reverse DNS lookup when you have an address and want its PTR records. The reverse direction is maintained independently from ordinary forward DNS. These IP tools do not enumerate every website on a server. A shared hosting address can serve many domains while its PTR record contains only a generic operator-selected name, or no useful name at all.
IP tools for connectivity and address arithmetic
Use the IPv6 test to compare requests to IPv4-only and IPv6-only endpoints from the current browser. It returns the observed source for each successful request. IP tools cannot infer complete dual-stack behavior from one ordinary website request, because the browser chooses one connection family for that request. Separate endpoint checks answer a more specific reachability question.
Use the subnet calculator to derive a range, mask, and exact address count from a CIDR prefix. The calculation runs locally and sends no probe to the range. That is an important distinction between these IP tools: a calculated first or last address is not a discovered active device, and a large total is not a list of machines currently connected to your network.
IP tools for remote latency and route observations
The HTTP headers check extends these IP tools into public website response diagnostics. It shows actual HEAD responses, redirect steps, field values and the probe's TLS verification state. These IP tools preserve incomplete evidence and disclose public measurement results before submission. Never include tokens or private information in a tested URL.
Use the ping test to collect five diagnostic packets from one Globalping probe, or online traceroute to inspect its reported route hops. These IP tools identify the actual remote origin and public target. Their measurements do not start from your browser. Review the public-results disclosure before starting; hostname targets are resolved through Google Public DNS and pinned to one public address. Remote IP tools retain missing replies, incomplete observations, and provider failures without turning them into an automatic outage declaration. Keep the protocol and probe network with the copied report so another person can interpret the path you actually tested.
IP tools for a public TCP service
Use the port checker when you need a TCP connection attempt to a particular public address and port, or a fixed preset of four or six ports. These IP tools distinguish a successful connection from refusal, timeout, unreachable paths and probe restrictions. The source is the site server, and no application payload is sent. IP tools cannot turn that connection into proof of correct TLS, working login or UDP reachability. Keep the tested address and timestamp with the report, especially when a hostname can select several destinations. These IP tools also explain when their own environment prevented a conclusive result.
Interpret the evidence from IP tools
Keep direct observations separate from estimates and administrative records. An endpoint can observe the source address of a connection. A registry can publish a network allocation. A geolocation provider can estimate where a network is used. IP tools become misleading when they silently substitute one of these concepts for another, especially when an interface presents every field with the same apparent certainty.
Record the observation time for live queries. DNS caches change, public addresses can rotate, and registration data can be updated. If two IP tools disagree, first confirm that they examined the same address, address family, source type, and time. Comparing a current IPv6 connection with an old IPv4 screenshot does not demonstrate that one tool is wrong. It describes different observations.
Read the limits of results from IP tools
A failed request does not always answer the underlying question. The IPv6 endpoint might be filtered or temporarily unavailable even if the device has other working IPv6 routes. A registry may rate-limit a query, and a DNS response may succeed with no records of the selected type. Reliable IP tools report the operation's actual outcome instead of turning every failure into a broad conclusion.
The DNS response code is a concrete example. NOERROR without answers, NXDOMAIN, and SERVFAIL have different meanings. IP tools should let you retain those differences in a copied report. Likewise, “country not provided” is different from a measured country, and “PTR missing” is different from “address unused.” Use the original result when seeking help so another person can interpret the evidence correctly.
Avoid unsupported privacy scores
An observed VPN exit can demonstrate routing for that connection, but it is not a complete anonymity certificate. Different applications, address families, DNS paths, and peer connections may behave differently. IP tools can contribute measurements to a privacy investigation, yet a simple green badge cannot replace an understood baseline. Be cautious about any conclusion that is broader than the test actually performed.
Use IP tools to investigate connection speed
The internet speed test measures browser-to-Cloudflare download, upload and HTTP latency after you choose a data budget and start it. These IP tools distinguish sequential HTTP throughput from a guaranteed access-line capacity. Standard mode permits up to 167 MB of test payload; data saver permits up to 7 MB, with network overhead additional. No test starts just by opening the page.
Speed-oriented IP tools preserve incomplete measurements and show their samples instead of inventing a score. Compare the same device, mode and background conditions when investigating Wi-Fi or VPN changes. Unlike remote Ping, this operation originates in the browser. These IP tools therefore answer a different question about the visitor’s current route.
Work through a network problem with IP tools
Start by writing down the expected behavior and the actual failure. Note the active network, device, browser or application, VPN state, and time. Then choose the smallest relevant check. IP tools are easier to interpret when each query has a purpose. Running every available test without an initial question often produces a pile of unrelated results rather than a clear explanation.
If a website name fails to open, query the appropriate DNS records first. A valid answer lets you move on to connection, TLS, or application behavior. If a mail setup is failing, inspect the relevant MX and TXT records rather than only the website's A record. IP tools should help you isolate layers instead of encouraging changes to settings that already work.
If an address appears in an unexpected location, compare the exact source address and your VPN or relay state. Registration country alone cannot settle a location dispute. If incoming connections fail, inspect the local service, firewalls, router translation, and possible CGNAT. IP tools can provide context for these investigations, but knowing a public address is only one piece of making an inbound service reachable.
Compare IP tools after one change
Compare Wi-Fi with cellular, or a VPN-connected state with a disconnected state, while keeping other conditions stable. Save the relevant before-and-after observations. IP tools are not a substitute for controlled comparison: several simultaneous changes can make it impossible to tell which change fixed the issue. Avoid repeatedly modifying production network settings merely because a diagnostic returned an unfamiliar value.
Share useful evidence from IP tools
Include the tool, exact query, source, time, response code, and relevant result. State whether the issue affects one application, one network, or several. IP tools often provide a copy control to preserve structured details, but review the copied text before sharing it. Remove credentials, unrelated personal information, and confidential hostnames from a public report.
Sources, scope and next steps
The methodology describes how observations and queries are performed, and the data sources explain provider roles and limitations. Each tool has a detailed guide below its interface. IP tools are most effective when they make a specific uncertainty smaller and suggest an appropriate next step, rather than promise to explain every aspect of a connection from one address.
This directory lists working operations with defined inputs. It does not label undeployed authoritative DNS observers or uncollected research as live results. As additional IP tools are developed, their measurement path, source, failure states, and supporting explanations need the same scrutiny. Useful coverage comes from reliable answers to distinct tasks, with enough context for a visitor to understand what remains unknown.
For mail-delivery investigations, the IP blacklist check asks two named mail lists after validating source controls. These IP tools keep listed, not listed, unavailable and unsupported results separate. Use the actual outbound mail server address, which may differ from your browser connection.
For forward naming questions, the hostname lookup combines separate A, AAAA and CNAME observations. These IP tools preserve alias paths, address families and per-query failures. Selected CDN hints include their observed names and provider references; they do not prove ownership or active delivery.
For local address planning, the CIDR calculator converts inclusive ranges, aggregates networks without filling gaps, and splits IPv4 or IPv6 prefixes. These IP tools use exact integer arithmetic and keep entered ranges in the tab. Large subdivisions use paged results; copy controls distinguish the current page from all output. IP tools for arithmetic do not establish ownership or reachability.
For mail-delivery questions, the email header analyzer adds local text inspection to these IP tools. It organizes Received records, interprets supported timestamps and retains unverified authentication assertions. Pasted headers stay in the tab, with no automatic address lookup. These IP tools cannot identify a person from a mail relay address.
For credential preparation, the password generator and PIN generator use browser cryptography without uploading their output. These local IP tools support bounded batches, explicit copying and clear controls. Numeric codes preserve leading zeros. IP tools that generate strings do not register credentials with another service, deliver verification messages or establish an account's security.