Subnet Overlap Checker — Detect Whether Two CIDR Blocks Overlap (Free)
Enter two IPv4 CIDR blocks (e.g. 192.168.1.0/24) and instantly find out whether they are identical, one contains the other, or they don't overlap at all. Useful for catching conflicts when designing firewall rules or VPC subnets.
Types of Subnet Overlap Relationships
A reference table of every possible relationship between two CIDR blocks.
| Relationship | Example | Description |
|---|---|---|
| Identical | 192.168.1.0/24 = 192.168.1.0/24 | Both CIDR blocks refer to exactly the same address range — they are the same subnet. |
| A contains B | 192.168.0.0/16 ⊃ 192.168.1.0/24 | CIDR A's address range fully contains CIDR B's range. B is a subnet carved out of A. |
| B contains A | 192.168.1.0/24 ⊂ 192.168.0.0/16 | CIDR B's address range fully contains CIDR A's range. A is a subnet carved out of B. |
| Partial overlap | — | This state never actually occurs. Because CIDR blocks are always aligned to power-of-two boundaries, if two blocks overlap at all, one must always be identical to or fully contain the other (see the FAQ below for details). |
| No overlap | 192.168.1.0/24 ∩ 192.168.2.0/24 = ∅ | The two CIDR blocks' address ranges don't overlap at all. They can be used side by side without conflict. |
To find the network and broadcast address from a single IP and subnet mask, see the subnet calculator , or to convert between an IP range and CIDR notation, see the IP range ⇔ CIDR converter .
What subnet overlap checking does
This tool tells you whether two networks written in CIDR notation overlap as ranges of addresses. Pairs such as `192.168.1.0/24` and `192.168.1.128/25` are easy to miss by eye — **the notation differs, yet one is entirely contained within the other** — and that oversight becomes the source of surprising behaviour in firewall rules and routing tables.
The check expands each CIDR into its network and broadcast addresses and asks whether the two intervals intersect. The verdict is one of: identical, one containing the other, partially overlapping, or no overlap at all. In VPC and on-premises address planning, **allocating ranges that will not collide as the estate grows is the whole point**, which makes this well suited to the design stage. Everything runs in your browser.
How to check for overlap
- Enter CIDR A Use a form such as `192.168.1.0/24`. The sample button loads an example for you.
- Enter CIDR B Enter the other network you want to compare, in the same form.
- Run the check Both address ranges are expanded and the relationship between them determined.
- Compare the ranges The start and end address of each CIDR is shown, so you can see for yourself where they meet.
Tips for getting more out of it
- Handy for checking firewall ACL rules or VPC subnet designs to make sure you haven't accidentally defined the same address range twice.
- A "contains" relationship is a normal, expected pattern when you carve a smaller subnet (like a /24) out of a larger allocation (like a /16) — it's not necessarily a problem.
- When setting up VPC peering or a VPN connection in the cloud, overlapping CIDR blocks on either side make routing ambiguous and cause connection errors. Always check for overlap before connecting.
- The "A range" and "B range" in the result are automatically rounded to the network and broadcast address of the matching block, even if the IP you typed wasn't the exact network address for that prefix length.
Where this helps
Planning VPC subnets
When creating several VPCs in the cloud, confirm the ranges do not collide so that peering remains possible later.
Designing a site-to-site VPN
If head office and a branch use the same private range, traffic will not pass once the tunnel is up. Check before you connect.
Auditing firewall rules
Inspect whether several rules target the same range, or whether one permits a wider range than intended.
Reviewing a routing table
Longer prefixes take precedence, so a route that contains another changes the behaviour. This makes that relationship plain.
Networking terms explained
- CIDR notation
- Writing a network address and a prefix length separated by a slash, as in `192.168.1.0/24`.
- Prefix length
- The number saying how many leading bits form the network portion. **The larger the number, the narrower the range.**
- Network address
- The first address of the range. It is not assigned to a host.
- Broadcast address
- The last address of the range, used to send to every host on that network.
- Containment
- The state in which one range falls entirely inside another. Combinations of `/24` and `/25` produce this readily.
- Private address space
- The three ranges `10.0.0.0/8`, `172.16.0.0/12` and `192.168.0.0/16`, free for use within an organisation. **That very freedom is what makes collisions between sites so common.**
FAQ
Side Note — Why CIDR Blocks Can Never "Partially" Overlap
Compare any two CIDR blocks and only three outcomes are possible: identical, one contains the other, or no overlap at all — a genuine "partial" overlap is mathematically impossible. This follows directly from the constraint that a CIDR block must always be a power-of-two size, positioned only at an address that's a multiple of that size (its alignment boundary).
An intuitive way to see this is to picture the set of all CIDR blocks as a binary tree. Start with /0 as the root, and every time the prefix length increases by one, a node splits into two children (the first half and the second half of its range). Under that structure, any two blocks are either the exact same node, one is an ancestor of the other, or they sit on completely separate branches — there's no way for two branches to cross halfway through.
This property is exactly what makes route summarization in routing tables well-defined. If partial overlap were possible, "which route should this packet prefer" would become genuinely ambiguous — but CIDR's design rules out that scenario by construction. In practice, most real-world routing breakage traces back to someone carving up IP ranges by hand without respecting this alignment rule, causing boundaries to drift unintentionally.