14 tools
Diagnostics and lookups: ping, DNS, WHOIS, IP, headers and more.
Answers about a domain, an IP or a request, run from our servers rather than your browser cache — so you see what users and crawlers see. Start with Diagnostics when something feels slow or unreachable, and with Lookup & Records when a DNS, TLS or mail change needs confirming.
Diagnostics
6
Lookup & Records
6
Encode & Convert
2
Other tool families
Not the right family? These are the neighbouring sets people usually need next.
Fresh answers
Edge-side resolvers and HTTP fetches show real user and bot views.
Email auth clarity
SPF, DKIM, DMARC checks with policy summaries for quick fixes.
Privacy-first
Minimal logging and short-lived processing - inputs are not stored beyond the request.
About
Resolve DNS, check headers, verify TLS, email auth, see your public IP, ASN and subnets — tuned for speed, clarity and privacy.
DNS propagation, HTTP headers and redirects, SPF/DKIM/DMARC, TLS expiry and chain checks, ASN/prefix lookups, IP visibility and subnet math live here. Server-side execution keeps answers consistent and layouts stay readable on mobile and desktop.
Requests run from the edge so you see what users and crawlers see, not your browser cache. Logging is minimal and packet captures are not stored beyond the request. Mail auth results include raw DNS plus policy summaries; headers show redirects, status codes, cache hints and security headers together.
Use these tools to validate launches, confirm DNS changes, verify CDN headers, audit TLS hygiene and fix email deliverability. Share links with your team without exposing tokens — inputs are fast, outputs are copyable, retries are instant.
FAQ
›Why do results differ by location?
CDNs, anycast routing, DNS caching, and geo-based policies can change what you see. Testing from the edge helps approximate user and crawler views.
›Do you store lookups or scans?
Tools run per request and are designed with minimal logging. Packet captures are not stored beyond the request.
›Can I validate email deliverability here?
You can check SPF/DKIM/DMARC and DNS records to catch common issues. Inbox placement also depends on reputation and content.
›What should I check before a launch?
Verify DNS, TLS expiry/chain, redirects and headers (cache/canonical/security), and confirm key ports are reachable.
When something is unreachable the question is always which layer failed: the name, the route, the port, the certificate or the application. These tools ask each of those questions separately, from our server rather than from your machine, which is what you want when you are trying to tell a local problem apart from one everybody else can see too.
Guides
See all 8 guidesHow to Check Whether a Port Is Open, and What the Result Means
Open, closed, and filtered are three different answers, and telling them apart is the whole skill. Here is what the TCP handshake reveals and why a firewall makes a port look filtered rather than closed.
Jul 07, 2026 · 7 min
Using Traceroute to Find Where a Connection Slows Down
Traceroute maps the routers between you and a host and times each one. The trick is reading it correctly: one slow middle hop usually means nothing, and a persistent jump at the end is the real problem.
Jul 09, 2026 · 9 min
How to Check If Your SSL Certificate Is Valid and Expiring Soon
A monthly check takes 30 seconds and prevents the worst outage of the year. Here's what the TLS checker shows, the common chain bugs, and the wildcard vs SAN gotcha.
Apr 22, 2026 · 12 min
DNS Propagation: Why Your Domain Change Isn't Live Yet
Why DNS changes take minutes or days to go live, how TTL actually controls it, and how to check propagation status globally when a launch depends on it.
Apr 19, 2026 · 13 min
How to Read a WHOIS Record and What Each Field Means
A field-by-field walkthrough of a WHOIS record: registrar vs registrant, the three dates that matter, name servers, status codes, and why half the contact fields are now redacted.
Jul 10, 2026 · 8 min
Reading HTTP Response Headers to Debug Caching and Security
The response headers tell you whether a CDN cached your page, how long a browser will hold it, and which security policies are in force. Here is how to read the ones that matter.
Jul 06, 2026 · 9 min
How to Read SPF, DKIM, and DMARC Results Without Being an Email Admin
A plain-language guide to the three DNS records behind email deliverability: what each one actually checks, how to read a real SPF string, what DMARC policies mean, and the failure patterns behind most 'our emails go to spam' tickets.
May 27, 2026 · 14 min
Subnets and CIDR Notation Explained, with a Calculator
What /24 and /26 really mean, how to find the network, broadcast, and usable host range, and a worked split of 192.168.1.0/26 you can follow by hand.
Jul 08, 2026 · 9 min
These tools are the exception to the browser-only rule, and they have to be. A web page cannot open a raw socket, send an ICMP packet or query a nameserver directly — the browser sandbox exists precisely to stop that. So every lookup here is issued from our server, and the answer describes the internet as our server sees it. The My IP tool is the one that genuinely reports your connection, because that request comes from you.
That distinction matters when you are debugging. If a DNS check succeeds from our resolver but your laptop still cannot reach the site, the record is fine and your local cache, VPN or corporate resolver is not. Same for a port check: an open result proves the service accepts connections from the public internet, and tells you nothing about a firewall rule that only affects your office.
When something is down, work upward in order: does the name resolve, does TCP connect, does TLS negotiate, does HTTP return what it should. Jumping to the middle of that chain is how people spend an afternoon on a certificate problem that was actually an expired domain.
Reading DNS in the right order
There are two different answers to any DNS question: what the authoritative nameserver holds, and what a given resolver has cached. Querying the authoritative servers directly shows the current truth; querying a public resolver shows what most users are getting right now. When those disagree, you are simply waiting out a TTL. Nothing “propagates” — records are pulled on demand and held for the TTL you published, so lowering the TTL to 300 seconds a day before a migration is the only real preparation.
The apex of a domain cannot hold a CNAME, because the record type conflicts with the SOA and NS records that must exist there. Providers work around this with ALIAS or flattening records that resolve to an address at query time. Get this wrong and mail stops, because the conflicting CNAME suppresses the MX record.
When you compare two nameservers, check the SOA serial. If it differs between them, one has not picked up the latest zone transfer, and you are chasing an inconsistency rather than a configuration error.
Traceroute tells the truth about the path, not the latency
Routers generate the ICMP time-exceeded messages traceroute depends on using their control plane, which is deliberately deprioritised compared to forwarding traffic. A middle hop showing 180 ms while the final destination answers in 30 ms is completely normal and means nothing is wrong. Only the last hop’s latency describes the actual round trip.
Rows of asterisks mean a hop did not reply, usually because ICMP is filtered there — not because packets are being dropped. Return paths are frequently asymmetric, so what you see is one direction of a two-way trip, and MPLS tunnels can hide several physical hops behind what looks like a single link. Use traceroute to find where a path changes provider or geography, not to measure performance.
What a TLS check should tell you
Expiry is the obvious thing and the least interesting one. The failure that costs people real time is an incomplete chain: the server sends its leaf certificate but omits the intermediate. Browsers paper over this by fetching the missing certificate through the AIA extension, so the site looks fine to you while curl, Java clients, older Android devices and payment webhooks all reject it. A chain check catches it before your partners do.
Also confirm the hostname appears in the SAN list rather than only the deprecated common name, that TLS 1.2 and 1.3 are offered while 1.0 and 1.1 are not, and that the certificate covers every hostname you actually serve. Combined with a header check — HSTS, the redirect chain, cache directives, whether the server leaks its exact version — you get a fairly complete picture of how a host presents itself.
Email authentication in three records
SPF lists the hosts allowed to send for your domain, and it has a hard limit of ten DNS lookups during evaluation. Chaining several vendor include statements blows past that limit and produces a permanent error, which many receivers treat as a failure. Count your lookups whenever you add a service.
DKIM signs the message with a private key while publishing the public key at a selector under the domain, so a receiver can prove nothing was altered in transit. DMARC ties the two together, adds alignment requirements between the visible From domain and the authenticated one, and tells receivers what to do when checks fail. Start at p=none with a reporting address, read the aggregate reports for a few weeks until you have found every legitimate sender, then move to quarantine and finally reject.
Common questions
- Is the lookup run from my computer or from your server?
- From our server, with the exception of My IP, which reports the address your own request arrived from. That is why results reflect our vantage point on the network rather than yours. For anything that depends on your local network, run the equivalent command on your own machine.
- How accurate is IP geolocation?
- Country-level accuracy is usually reliable; city-level is a guess based on registry data and network topology, and it is frequently wrong by hundreds of kilometres. Mobile carriers, VPNs and CGNAT make it worse by mapping large user populations to a single gateway. Treat it as a hint, never as evidence.
- Why is WHOIS data mostly hidden?
- Registrars redact personal contact details for most domains to comply with GDPR and similar privacy rules, replacing them with a proxy address. Registration and expiry dates, registrar name and nameservers stay visible and are usually what you need anyway. Some ccTLDs redact even more.
- What is the difference between a closed and a filtered port?
- Closed means the host replied with a TCP reset — something is there, nothing is listening on that port. Filtered means nothing replied at all, so a firewall silently dropped the packet. Filtered results are ambiguous by design; that is the point of dropping rather than rejecting.
- How long do DNS changes take to appear?
- As long as the previous TTL on the record, because resolvers keep serving the cached copy until it expires. A record with a 24-hour TTL can take a full day to turn over worldwide. Lower the TTL well before you plan the change, not after.
- What does an ASN lookup tell me?
- It maps an IP address to the autonomous system that announces it, which usually identifies the hosting provider, cloud region or ISP behind an address. That is useful for spotting whether traffic comes from a residential network or a datacentre. It does not identify an individual customer of that provider.
- Do you log the domains and addresses I look up?
- We keep short-lived request records for rate limiting and abuse prevention, and nothing is tied to an account or profile. The data being queried is public registry and DNS information in the first place. Nothing you look up is shared or sold.
- Why does my public IP change?
- Most residential connections get a dynamic address from the ISP that can change on reconnection or lease expiry. Mobile networks also place many subscribers behind CGNAT, so the address you see belongs to the carrier gateway rather than to your device. A static address usually requires a business plan.