Why convert ranges to CIDR?
Firewalls, cloud security groups (AWS, Azure, GCP), routers and .htaccess rules usually want CIDR blocks, not start–end ranges. Most ranges don’t line up with a single block. For example, 10.0.0.1 – 10.0.0.10 needs five blocks: /32, /31, /30, /31, /32. Working that out by hand is error-prone. One wrong bit can open your network to the wrong people or lock out the right ones.
Our converter always produces the minimal exact set of blocks: nothing missing, nothing extra.
Summarising (aggregating) routes and ACLs
Over time, allow-lists and route tables collect duplicates, overlapping entries and neighbouring blocks that could be combined. The Merge tab:
- removes entries already covered by bigger ones (
10.0.1.44inside10.0.1.0/24) - joins adjacent blocks (
10.0.0.0/25+10.0.0.128/25+10.0.1.0/24→10.0.0.0/23) - accepts mixed input (CIDRs, single IPs, masks and dash ranges) in any order
Fewer entries mean faster rule evaluation, smaller routing tables and far easier audits.
Exact, never approximate. Route summarisation on routers sometimes deliberately over-covers (a “summary” that includes unused space). This tool never does that. The output covers exactly the addresses you entered, so it’s safe for security rules.
Cisco wildcard masks
Cisco IOS ACLs and OSPF use wildcard masks, the inverse of a subnet mask. 10.1.0.0/16 becomes 10.1.0.0 0.0.255.255, and a single host becomes host 10.1.2.3. Choose “Cisco wildcard” in the Range → CIDR tab to get ready-to-paste lines.