When to use this API
When you need to answer a networking question — subnet math, DNS record lookups, WHOIS queries, SSL certificate inspection, or value encoding — without installing dig, whois, openssl, or a subnet calculator. This API replaces a handful of CLI tools with one unauthenticated GET per question. It's particularly useful for subnet breakdowns: pass a CIDR block and get assignable host counts, broadcast addresses, and wildcard masks back in one call. It does not do ping, traceroute, port scanning, or anything interactive — it's purely calculational and lookup-based. For anything requiring real-time connectivity testing, reach for a different tool.
Calculating subnet details for a CIDR block
"How many usable hosts are in 192.168.1.0/24?"
Pass any IPv4 address with a CIDR prefix to /ip/{subnet} and get back the full subnet breakdown. The only probe in the database is the ubiquitous home-network prefix 192.168.1.0/24 — a dull example, but it's what the data gives us, and the response shape is the same for any CIDR.
curl "https://networkcalc.com/api/ip/192.168.1.0/24" | head -c 10000
{
"status": "OK",
"meta": {
"permalink": "https://networkcalc.com/subnet-calculator/192.168.1.0/24",
"next_address": "https://networkcalc.com/api/ip/192.168.1.1/24"
},
"address": {
"cidr_notation": "192.168.1.0/24",
"subnet_bits": 24,
"subnet_mask": "255.255.255.0",
"wildcard_mask": "0.0.0.255",
"network_address": "192.168.1.0",
"broadcast_address": "192.168.1.255",
"assignable_hosts": 254,
"first_assignable_host": "192.168.1.1",
"last_assignable_host": "192.168.1.254"
}
}
The assignable_hosts field is 254, not 256 — the API subtracts the network address (.0) and broadcast address (.255) for you, eliminating a common off-by-two mistake. The meta.next_address link lets you walk a subnet host-by-host without computing the next IP yourself. The endpoint also accepts comma-separated CIDR blocks like /ip/10.0.0.0/24,172.16.0.0/24 to compare subnets in one call.
A /24 subnet at 192.168.1.0 has 254 assignable hosts (192.168.1.1 through 192.168.1.254), a subnet mask of 255.255.255.0, a wildcard mask of 0.0.0.255, and a broadcast address of 192.168.1.255. The network and broadcast addresses are reserved, so the usable range starts at .1 and ends at .254.
Looking up DNS records for a domain
"What DNS records does google.com have?"
The /dns/lookup/{hostname} endpoint returns A, CNAME, MX, NS, SOA, and TXT records in a single call — no need to run dig six times. The probe data uses google.com, which is the boring default for DNS demos, but the response happens to be unusually rich in TXT records, making it worth studying.
curl "https://networkcalc.com/api/dns/lookup/google.com" | head -c 10000
{
"status": "OK",
"hostname": "google.com",
"records": {
"A": [
{ "address": "142.251.45.206", "ttl": 123 }
],
"CNAME": [],
"MX": [
{ "exchange": "smtp.google.com", "priority": 10 }
],
"NS": [
{ "nameserver": "ns2.google.com" },
{ "nameserver": "ns4.google.com" },
{ "nameserver": "ns1.google.com" },
{ "nameserver": "ns3.google.com" }
],
"SOA": [
{ "nameserver": "ns1.google.com", "hostmaster": "dns-admin.google.com" }
],
"TXT": [
"v=spf1 include:_spf.google.com ~all",
"google-site-verification=wD8N7i1JTNTkezJ49swvWW48f8_9xveREV4oB-0Hf5o",
"apple-domain-verification=30afIBcvSuDV2PLX"
]
}
}
The TXT records array is a goldmine for domain intelligence. Google's TXT records reveal its entire cross-platform verification stack: Apple, DocuSign, Facebook, Microsoft, and Cisco all have domain verification tokens stored there. The SPF record (v=spf1 include:_spf.google.com ~all) tells receiving mail servers to trust Google's IP ranges for outbound mail — if you're debugging mail delivery for a Google Workspace domain, this is the first field to check. Empty record types come back as [] rather than being omitted, so you can safely check records.CNAME.length without guarding against undefined.
Google.com has an A record at 142.251.45.206, MX records routing mail through smtp.google.com (priority 10), four nameservers (ns1–ns4.google.com), and TXT records including an SPF policy and domain verification tokens for Apple, DocuSign, Facebook, Microsoft, and Cisco. There are no CNAME records on the root domain (as expected — CNAMEs can't coexist with other record types at the apex).
Inspecting an SSL/TLS certificate
"When does google.com's SSL certificate expire?"
The /security/certificate/{hostname} endpoint fetches and parses the live SSL/TLS certificate for any hostname. No openssl s_client plumbing, no parsing PEM blocks. The ?port= query parameter lets you check non-standard ports; omit it and the API defaults to 443.
curl "https://networkcalc.com/api/security/certificate/google.com?port=443" | head -c 10000
{
"status": "OK",
"meta": {
"protocol": "https:",
"hostname": "google.com",
"port": "443"
},
"certificate": {
"issued_to": "*.google.com",
"issued_by": "WR2",
"valid_from": "2026-03-23T08:36:28.000Z",
"valid_to": "2026-06-15T08:36:27.000Z",
"alternate_names": [
"DNS:*.google.com",
"DNS:*.cloud.google.com",
"DNS:*.google.ca",
"DNS:*.google.de"
]
}
}
Google's certificate is valid for roughly 90 days — a deliberate choice reflecting the industry push toward short-lived certificates that limit the blast radius of a key compromise. The issued_by value WR2 is a Google Trust Services intermediate CA, meaning Google operates its own certificate authority rather than relying on DigiCert or Let's Encrypt. The full alternate_names list in the probe contains 80+ entries, including dozens of .cn domains — an artifact of Google's China-specific infrastructure strategy baked directly into the certificate. The meta.port field is always a string ("443"), even when passed as an integer in the query, which matters if you're doing strict type comparisons.
Google.com's SSL certificate is valid from 2026-03-23 to 2026-06-15 — about a 90-day window. It's issued to *.google.com by WR2, a Google Trust Services intermediate CA. The certificate covers 80+ Subject Alternative Names, including Google's country-specific domains and its China-domain portfolio.
Pitfalls
- The
/binary/{number}path expects binary digits, not a decimal number. Passing/binary/255returnsINVALID_NUMBER_FORMAT. Use/binary/11111111to convert the binary value 0b11111111 to decimal, octal, and hex. The endpoint name is misleading — it interprets the input as binary, not as a decimal number to be converted to binary. - The
/encoder/{value}default encoding is URL encoding, not Base64. If the input has no special characters (likehello), theencodedoutput is identical to theoriginal— which looks like the endpoint did nothing. Pass?encoding=base64or?encoding=base64urlto get a visible transformation. - Certificate
alternate_namesarrays can be enormous. Google.com's response contains 80+ SANs. Always pipe throughhead -c 10000when exploring — the raw response can easily exceed 5 KB for major domains. - DNS TTL values are point-in-time snapshots. The
ttlin an A record is the remaining seconds at the moment of the lookup, not the record's configured TTL. Two lookups a minute apart will show different values.
One-line summary for the user
I can calculate IPv4 subnet breakdowns, look up DNS records, inspect SSL/TLS certificates, query WHOIS data, and encode/decode values — all from a single free, unauthenticated API at networkcalc.com.