No signup. No data sent anywhere. Pure client-side math.

CIDR Aggregator

Paste a list of IPs, ranges, or CIDR blocks — get back the smallest CIDR set that covers the same addresses. Use it to consolidate firewall rules, clean up cloud security groups, optimize route tables, or simplify allowlists. Built by Datastrive, a Chicago managed IT and structured cabling provider. IPv4 and IPv6 supported.

  • Mixed input formats accepted
  • IPv4 + IPv6 in same input
  • Auto-aggregates as you type

Input

One entry per line. Accepts CIDR (10.0.0.0/24), single IPs (8.8.8.8), and ranges (10.0.0.5-10.0.0.20). IPv4 and IPv6 can be mixed. Whitespace, commas, and semicolons separate entries.

Aggregated output

How CIDR aggregation works (and why it matters)

Aggregation collapses a list of IP addresses, ranges, or CIDR blocks into the smallest set of CIDR blocks that covers the same addresses. The math is exact — nothing is added, nothing is removed.

  1. Why aggregate at all? Smaller rule sets are faster (firewall ACLs and route tables match top-to-bottom), easier to audit, and less prone to drift. A firewall with 47 redundant rules covering the same /22 will check all 47 on every packet match attempt — consolidating to one rule reduces CPU, simplifies rule reviews, and makes change management cleaner.
  2. Two CIDRs only aggregate if they’re aligned and adjacent To merge into a single block, two CIDRs must be the same size, and the lower one must start at an aligned boundary. 192.168.0.0/24 and 192.168.1.0/24 aggregate to 192.168.0.0/23. But 192.168.1.0/24 and 192.168.2.0/24 do not — they’re adjacent, but a /23 starting at .1.0 isn’t aligned (a /23 boundary requires the third octet to be even).
  3. Adjacent IP pairs become /31s If you have 10.0.0.6 and 10.0.0.7, the tool produces 10.0.0.6/31 — one rule covering both. But 10.0.0.5 and 10.0.0.6 stay as two /32s because /31 alignment requires the lower IP to be even.
  4. Misaligned CIDRs get corrected silently If you input 192.168.5.42/24, the tool treats it as 192.168.5.0/24. The host bits below the prefix length aren’t part of the network identifier — they’re just noise. Most firewalls do this same correction internally; this tool surfaces it explicitly.
  5. Cross-octet ranges don’t always collapse cleanly The range 10.0.0.255-10.0.1.0 contains exactly two addresses, but they sit on opposite sides of a /24 boundary — so the output is two /32 blocks, not a /31. CIDR alignment rules don’t cross arbitrary boundaries.
  6. IPv6 aggregation works the same way The math is identical — just with 128-bit addresses instead of 32. Two adjacent /48s on an aligned boundary collapse to /47. The tool handles all standard IPv6 notations including :: zero-compression and IPv4-embedded forms like ::ffff:192.0.2.1.
  7. Don’t aggregate across security boundaries If 10.0.1.0/24 is your dev VLAN and 10.0.2.0/24 is your prod VLAN, aggregating to 10.0.0.0/22 in a firewall ACL would also cover unrelated networks. Aggregation is a math operation, not a policy decision — review what each block actually means before consolidating rules.
  8. Order doesn’t matter; duplicates and overlaps merge silently Paste your list in any order. Duplicate entries collapse. Overlapping CIDRs (a /16 that contains a /24) reduce to just the larger block. The output is always sorted in network-address order.

Frequently asked questions

What does this tool actually do?

It takes a list of IP addresses, ranges, or CIDR blocks and outputs the smallest set of CIDR blocks that covers the same addresses — no more, no less. The aggregation is exact and reversible: the union of the output blocks equals the union of the inputs.

It runs entirely in your browser. Your input never leaves your machine.

Why would I need to aggregate CIDRs?

Common scenarios: consolidating firewall rules that grew organically over years, cleaning up AWS or Azure security groups, simplifying route table entries, summarizing BGP advertisements, condensing IP allowlists or blocklists, and reducing the size of CSV files containing IP ranges.

For network engineers, the most common payoff is firewall and ACL cleanup — old rules accumulate over time as networks grow, and most are individually correct but collectively redundant.

What input formats does it accept?

Three formats, mixed freely:

CIDR notation: 10.0.0.0/24 or 2001:db8::/32

Single IP: 8.8.8.8 or 2001:db8::1 (treated as /32 or /128)

Range: 10.0.0.5-10.0.0.20 or 2001:db8::1-2001:db8::ff

Entries separate on newlines, commas, semicolons, and whitespace. IPv4 and IPv6 can be mixed in the same input — output is split into per-family sections.

Why doesn’t 192.168.5.42/24 stay as I entered it?

Because 192.168.5.42/24 isn’t actually a CIDR block — it’s a host inside the 192.168.5.0/24 network. The /24 prefix means “the first 24 bits identify the network, the last 8 bits identify a host.” So 192.168.5.42/24 and 192.168.5.99/24 describe the same network, just with different host bits.

The tool normalizes to the canonical form (network address + prefix). Most firewall and routing software does this same normalization internally.

Why don’t 10.0.0.255 and 10.0.1.0 merge into a /31?

Because /31 alignment requires the lower IP to have its last bit set to 0 — i.e., the lower IP must be even when treated as a 32-bit integer. 10.0.0.255 ends in ...11111111 (odd), so a /31 starting there would also need to include 10.0.1.0, which it does numerically — but the /31 block boundary doesn’t actually start at .255.

The valid /31 containing both would be 10.0.0.254/31, which covers .254 and .255. To include .255 and .1.0 in a single block, you’d need 10.0.0.0/23 — covering 512 addresses. Since you only wanted 2, two /32 entries is the minimum-size correct answer.

Are there limits on how much I can paste?

Theoretically no — the algorithm is fast (O(n log n) for the sort plus linear merge and decompose). Practically, the browser will start to struggle past ~10,000 entries because of the rendering, not the math. For larger workloads, run the same algorithm via a script.

Most real-world cleanup jobs are in the 50–500 entry range, which the tool handles instantly.

Does this work for IPv6?

Yes, fully. Aggregation math is identical for IPv6 — just with 128-bit addresses. The parser handles all standard notations: :: zero-compression, IPv4-embedded forms like ::ffff:192.0.2.1, and bracketed forms like [2001:db8::1].

Mixed v4/v6 input works fine; output is split into separate sections per address family since they can’t aggregate across families.

Can I export the result for a specific firewall vendor?

The output panel offers several formats: line-per-entry (the default, works for most tools), comma-separated (good for AWS security group source lists), and JSON array (for scripting). For vendor-specific syntax (Cisco IOS, JunOS, ufw, iptables), copy the line-per-entry format and pipe through a quick sed or template.

If there’s a format you’d find genuinely useful as a built-in option, let us know.

Need help cleaning up actual firewall rules?

This tool gives you the math. Turning aggregated CIDRs into a clean, audited firewall configuration — with proper change-control, rollback plans, and the segmentation policy still intact — takes more than a calculator. Datastrive does network audits, firewall consolidation, and structured cabling for businesses across the Chicago area.

Talk to Datastrive →