Half the firewall rules we audit on takeover have a CIDR mask that doesn’t match what the operator thought it did. Someone wrote /26 when they meant /27, or pasted 192.168.10.0/24 next to a host address that actually lives outside the block. The fix is always the same: stop arguing about it and recompute. The PortJar CIDR Calculator does that in one paste — no shell, no spreadsheet, no mental arithmetic over a 32-bit boundary.
What the tool does
You give it any IPv4 CIDR — 10.42.7.128/26, 192.168.0.0/24, 203.0.113.7/29 — and it returns the network address, the broadcast address, the first and last usable host, the total host count, the netmask in dotted-quad form, and the wildcard mask. All of the math runs in the browser. Nothing leaves the page, nothing is logged, and the answer is identical whether you type a host address or the network address — the tool normalises to the block.
That last point matters more than it sounds. Half the disagreements about a CIDR boil down to one party reading 10.0.0.5/24 as “the network is 10.0.0.5” rather than “this address belongs to 10.0.0.0/24.” The calculator silently fixes that and shows both forms.
How to use it
Open portjar.com/tools/cidr-calculator, paste the CIDR, and read the result. There is no submit button, no API call, no waiting. The output is structured into labelled rows so you can copy a single field — the broadcast, say, or the wildcard — into a firewall rule, a Terraform variable, or a ticket without grabbing surrounding text.
If you are sizing a new allocation rather than checking an existing one, type the prefix length next to the address you want the block to start at, and the calculator will tell you exactly which host range you have to work with.
When you’d reach for it
- Firewall rule disputes. Two engineers are looking at the same rule and disagree about whether a given host falls inside it. Paste the CIDR and the host into the calculator and the answer settles itself.
- Sizing a new VPC subnet. You need a block that fits 60 hosts. The calculator reminds you that /26 gives 62 usable, /25 gives 126, and /27 only gives 30 — no off-by-one regrets after the Terraform apply.
- Verifying a customer-supplied range. A vendor sends “use 198.51.100.16/28 for the peering.” Before you trust it, the calculator confirms it’s actually a valid block (the address aligns with the mask) and tells you what the first and last hosts will be.
- Reading bastion or cloud logs. A SIEM alert shows traffic from
198.51.100.231and an allowlist of198.51.100.224/27. Calculator says hosts run from .225 to .254 — so .231 is inside, not outside. - Migrating legacy notation. Older docs sometimes show a netmask (255.255.255.224) instead of a prefix. The calculator accepts the CIDR form and produces both, so you can cross-reference.
What to make of the output
The numbers that surprise people are at the edges. A /24 reports 254 usable hosts (256 minus the network and broadcast). A /31, per RFC 3021, reports 2 usable hosts — there is no separate network or broadcast for a point-to-point link. A /32 is a host route: one address, no network/broadcast distinction at all. Both of those are correct, and both will save you from carving a /30 where a /31 would have been more efficient.
The wildcard mask is the bit you copy into ACLs on older Cisco gear and into some Ansible filters. It is the bitwise inverse of the netmask — the calculator hands it to you so you don’t have to compute it under pressure.
If you paste an address that doesn’t align with the mask, the calculator does not error. It returns the block that the address belongs to. That is the right behaviour for a tool whose job is to remove ambiguity, but it is also the behaviour that tells you, gently, that the address you typed wasn’t actually the network address you assumed.
Stack Harbor uses the CIDR Calculator at every network handoff — peering setup, cutover, takeover audit — as part of environment management.