Firewall rules, allowlists, and access controls are usually written as CIDR ranges such as 192.168.1.0/24, but the question that matters in an incident is concrete: is this one address inside that range or not? Doing the subnet maths by hand is error-prone, especially at boundaries like the network address itself and the broadcast address. This tool answers the membership question directly. Give it an IPv4 address and a CIDR range and it tells you yes or no, and shows the range boundaries so you can see why. It is a membership test, not a subnet calculator: it does not split networks or list hosts.
Quick Answer: Enter an IPv4 address and a CIDR range such as 192.168.1.0/24, then click Check for a yes/no answer.
Free Online Tool
IP in CIDR Range Checker
Answer yes or no: does this IPv4 address fall inside this CIDR range?
How to Use the IP in CIDR Range Checker
- Type the IPv4 address you want to test.
- Type the CIDR range, including the slash and prefix length.
- Click Check.
- Read the yes/no verdict and the range start and end shown beside it.
- Test the boundary addresses too: the network address and the last address.
- Adjust the prefix length if the range is wider or narrower than you intended.
Key Features
- Exact yes/no membership verdict for IPv4 CIDR ranges.
- Shows the first and last address of the range.
- Handles every prefix from /0 to /32.
- Treats the network and broadcast addresses as members of the range.
- Validates both inputs and reports which one is malformed.
- Runs entirely in the browser with no data sent anywhere.
What the Result Means
Yes means the address lies between the range start and end inclusive, so any rule written for that range applies to it. No means the address is outside, even if it shares the first octets: 192.168.2.5 is not in 192.168.1.0/24, however similar it looks. A /32 range contains exactly one address, and a /0 range contains every IPv4 address, so if your test surprises you, check the prefix length first: one digit there changes the range by a factor of two.
Worked Example
Suppose a rule allows 10.20.30.0/24 and a suspicious login comes from 10.20.30.200. Testing that address returns YES, with the range shown as 10.20.30.0 to 10.20.30.255, so the login used an allowed address and the rule is not the problem. Testing 10.20.31.5 returns NO, because the third octet differs, which means a different rule or a misconfiguration is involved. Testing the boundary 10.20.30.0 itself returns YES, confirming the range is inclusive.
Best Practices and Tips
- Always test the first and last addresses of a range, not just a middle address.
- When a rule does not match as expected, check whether the prefix is /24 when you meant /23 or vice versa.
- Remember that membership is about the range, not about whether the address is assigned or in use.
- For allowlists, test an address you intend to block as well, to confirm it falls outside.
- Document the range alongside the verdict when you report an incident decision.
Common Mistakes to Avoid
- Assuming addresses that share three octets must be in the same /24.
- Forgetting that the network address itself is inside the range.
- Writing the range without a prefix length and expecting a guess.
- Mixing up /24 with 255.255.255.0 arithmetic when the prefix is not a multiple of eight.
Frequently Asked Questions
Is the broadcast address inside the range?
Yes, for this membership test. The range is inclusive of both ends; whether a host may use the broadcast address is a separate question.
What does /24 mean?
It means the first 24 bits are the network part, leaving 8 bits for hosts: 256 addresses in total, from x.x.x.0 to x.x.x.255.
Does this work for IPv6 ranges?
No, this tool covers IPv4 only. IPv6 membership uses the same idea but with 128-bit arithmetic.
Why is 10.0.0.5 not in 10.0.1.0/24?
Because the third octet differs. A /24 fixes the first three octets, so only 10.0.1.0 through 10.0.1.255 match.