CIDR

CIDR Merger

Collapse IPv4 CIDRs into the smallest exact address union

IP & Routing
πŸ”’ 100% client-side β€” your data never leaves this page
Maintained by Evanβ€’Updated: September 30, 2026

Produce the exact union of IPv4 CIDRs, deduplicating and combining overlapping or adjacent ranges without filling gaps. Host bits normalize to zero; any invalid line blocks merged output. Limit: 1 MiB, 1000 non-empty lines.

Addresses and networks are processed in this page. No network probes or input drafts; analytics contains fixed action names and counts only.

Page reading mode

The full guide also includes pitfalls, worked examples, snippets, FAQs, and related tools for checking results or troubleshooting.

About this tool

Reduce an IPv4 CIDR list while preserving its exact address set. The merger normalizes host bits, removes duplicates, combines overlapping or adjacent ranges, and expresses the union as the smallest aligned CIDR list. Two adjacent /25 halves become a /24, but separated addresses remain separated; gaps are never filled merely to shorten the list. The summary distinguishes input lines, unique normalized CIDRs, inputs with host bits cleared, output blocks and union address count. Every non-empty line must be valid before merged output is produced, so a malformed entry cannot silently disappear from an allowlist. Limits are 1000 non-empty lines and 1 MiB. This is set aggregation rather than ordered firewall-rule evaluation: actions, priorities and exceptions are not represented. All calculation and TSV export run locally without draft storage.

Suggested Workflow

Scenario Recipes

01

Consolidate two aligned allowlist halves

Goal: Remove redundant coverage without adding hosts

  1. Enter 192.0.2.0/25, 192.0.2.128/25 and 192.0.2.10/26 on separate lines.
  2. Run and confirm one output, 192.0.2.0/24, with 256 union addresses.
  3. Check that every source entry had the same policy meaning before exporting the aggregate.

Result: One exact /24 replaces the three overlapping inputs.

Failure Clinic (Common Pitfalls)

A shorter policy silently allows additional addresses

Cause: A covering supernet and an exact aggregate are different operations. A convenient common prefix may include gaps absent from the source list.

Fix: Use the exact output list, even when it contains several blocks. Check the union count and source meaning before replacing allowlist entries.

Duplicate coverage and duplicate input are mixed up

Cause: A /25 inside a /24 is a distinct normalized CIDR, yet contributes no additional addresses to their union.

Fix: Read input count, unique normalized CIDRs and union address count separately. None of them describes ordered allow/deny rule behavior.

Production Snippets

Aggregation preserves the exact set, including gaps

text

192.0.2.0/25 + 192.0.2.128/25
-> 192.0.2.0/24 (256 addresses)

192.0.2.0/32 + 192.0.2.2/32
-> 192.0.2.0/32
   192.0.2.2/32 (2 addresses)

The second pair cannot collapse without adding .1 or .3.

Frequently Asked Questions

When can two /25 blocks become a /24?

When they are the two aligned halves of that /24. 192.0.2.0/25 and 192.0.2.128/25 combine into 192.0.2.0/24 with exactly 256 addresses.

Will the merger bridge a gap?

No. 192.0.2.0/32 and 192.0.2.2/32 remain two blocks. A broader CIDR would add addresses absent from the input, violating exact union semantics.

How are duplicate and contained networks counted?

Input count includes every non-empty line. Unique count deduplicates normalized CIDR strings; contained but different CIDRs remain distinct inputs. Output and union address count eliminate duplicate coverage.

What if one line has an empty prefix or extra slash?

The entire merged result is withheld and the invalid line is identified. /0 must be explicit; an empty slash, /0x10 or /24/junk never becomes a valid network.

Can I merge IPv6 or mixed address families here?

This tool accepts IPv4 only. IPv6 input is rejected explicitly. Do not interpret a rejected IPv6 row as permission to drop it from a mixed network policy.

Is the output equivalent to my firewall configuration?

Only if the input represents an unordered set with one shared meaning. Ordered allow/deny rules, priorities, ports and routing actions require their own semantic review before replacing rules with aggregates.

Keep browsing