Media tools are next. Everything ships the same way: it runs in your tab, or it does not ship.
Network & DNS
Tools for the layer under your application: what resolvers answer for your domain, when a change you made actually reaches them, and where a subnet boundary really sits. The DNS tools talk to the network the same way your browser already does, over HTTPS from your tab, so there is no probe server between you and the answer; the subnet calculators are pure math and never send anything at all.
2 tools. All in your browser.
Nothing you paste is uploaded, and once a tool has loaded it keeps working offline. Free, no signup.
IP addressing
2 tools
Every subnetting question is a boundary question: where in the address do the network bits end? The IPv4 calculator puts that boundary on a clickable 32-bit bar and derives network, broadcast, host range, netmask and wildcard mask live, splits blocks into smaller subnets, and knows the special cases that plain math misses, from RFC 1918 and CGNAT ranges to the five addresses AWS and Azure reserve per subnet. The IPv6 calculator does the 128-bit side: RFC 5952 compression, /64 counts, address types, reverse DNS zones and nibble-aligned splits.
The parsers ship with the page, so a tool keeps working after you go offline.
Instant, as you type
Every tool runs the moment you type. No run button, no waiting, nothing to install.
Free forever, no signup
No account, no paywall, no trial that expires. All 70+ tools, free for everyone.
Why these tools run in the browser too
Most DNS lookup sites work by relaying your query to their own servers, which then run the actual lookups and log them. For DNS that design is unnecessary: the large public resolvers answer DNS-over-HTTPS requests directly, with the CORS headers that let a page query them from your tab. So the tools here skip the middleman. The request your browser sends is the same request a checker backend would send, except nobody in between sees which domains you are watching, and the latency you read is your latency, not a data center's. The subnet calculators go one step further: subnet math needs no network at all, so the addresses you type never leave the page, which matters when they describe your internal topology.
What a browser can and cannot see
Honest limits, because DNS checker sites tend to blur them: a browser cannot open port 53, so classic resolvers without DoH, including your ISP's, stay out of reach. And the big public resolvers are anycast networks, meaning each one gives a single answer from the site nearest to you rather than one answer per country. What the browser can do is compare seven independent resolver networks, read the real TTL countdowns from their caches, and query the record types that matter in a migration: A and AAAA for the switch itself, MX and TXT for mail, NS and SOA for the delegation. That covers the question people bring to these tools, which is not "what does DNS look like from Nairobi" but "has my change landed yet".
Questions from the layer under your app
Why do dig, nslookup and my browser give different answers?
Because they ask different resolvers and obey different caches. dig queries the resolver in your system configuration unless you name one with @1.1.1.1, nslookup may fall back to a different server and prints a shortened answer, and the browser has its own host cache on top of the operating system one. Chrome even keeps a socket to the old address alive after the DNS entry changed. When the three disagree, the machine that is right is the authoritative nameserver, and everything else is a cache with its own countdown.
Which resolver should I query when debugging a DNS problem?
Query at least three, and know what each one tells you. The authoritative nameserver gives ground truth, so ask it directly with dig @ns1.example.com to confirm what you actually published. A large public resolver such as 1.1.1.1 or 8.8.8.8 shows what most of the internet currently believes. Your own configured resolver shows what your machine sees. Disagreement between the second and the third is a cache, disagreement with the first means the change never landed.
What cannot be diagnosed from a browser tab?
Anything that needs a raw socket. A browser cannot send an ICMP echo, so no ping and no traceroute; it cannot open UDP port 53, which is why in-browser DNS tools go through DNS-over-HTTPS and see what the DoH provider sees rather than what a plain UDP query would return; and it cannot open an arbitrary TCP port, so no port scan and no SMTP banner check. For those, the command line or a probe server is the only honest answer.
How do I check DNS, TLS and HTTP from the command line?
Three commands cover almost everything. dig +short A example.com @1.1.1.1 for records, adding +trace when you want the walk from the root. openssl s_client -connect example.com:443 -servername example.com -showcerts for the certificate chain the server actually sends. curl -sv https://example.com -o /dev/null for the handshake, the redirects and the response headers in one pass. Each names its own failure precisely, which a browser error page does not.
Do I still need to plan subnets carefully inside a cloud VPC?
Yes, mostly because of what the provider takes off the top and because resizing is painful. AWS reserves five addresses in every subnet, so a /28 leaves eleven usable, and Azure reserves five as well; a /29 is the smallest subnet AWS accepts and a /28 the smallest in Azure. The VPC CIDR itself cannot be shrunk after creation, and overlapping ranges are what makes a later VPC peering or VPN to another network impossible, which is the mistake that costs a migration rather than an afternoon.