CIDR Range Converter
Convert IPv4 CIDRs and inclusive ranges with exact coverage
IPv4 only. CIDRs normalize host bits; inclusive ranges produce an exact minimal CIDR cover. /31 uses two point-to-point endpoints and /32 one address; other host counts use the traditional minus-two model. Cloud reservations are separate. Combined input limit: 1 MiB.
Addresses and networks are processed in this page. No network probes or input drafts; analytics contains fixed action names and counts only.
The full guide also includes pitfalls, worked examples, snippets, FAQs, and related tools for checking results or troubleshooting.
About this tool
Move between one IPv4 CIDR block and an inclusive first-to-last address range. CIDR mode retains the original address in the summary and clears host bits for the network: 192.0.2.17/28 becomes 192.0.2.16/28, covering .16 through .31. Range mode returns a minimal exact CIDR cover, without widening the range to a convenient aggregate. Prefixes must be complete decimal integers from 0 through 32. For /0β/30, the summary uses conventional network/broadcast reservations; /31 displays two point-to-point endpoints and /32 one address, with no broadcast label. Cloud or provider reservations need a separate check. Combined input is limited to 1 MiB. Results and TSV export update only after an explicit run; editing clears the old result. Calculation is local and inputs are not saved.
Failure Clinic (Common Pitfalls)
A network boundary is mistaken for the original host
Cause: CIDR normalization clears host bits: 192.0.2.17/28 refers to a network starting at .16.
Fix: Compare the original-address summary with the normalized CIDR and inclusive bounds before copying the range into a policy.
The last /31 address is reserved as broadcast by habit
Cause: The ordinary subnet minus-two model does not describe RFC 3021 point-to-point /31 links or a /32 host route.
Fix: Use the endpoint count for /31 and /32. For other prefixes, treat traditional host counts as a model and check extra provider reservations separately.
Suggested Workflow
Scenario Recipes
Cover a small allowlist without adding addresses
Goal: Keep the exact .1β.2 interval
- Choose Range to CIDRs. Enter 192.0.2.1 as first address and 192.0.2.2 as last.
- Run and confirm two outputs: 192.0.2.1/32 and 192.0.2.2/32.
- Verify the total is 2 before copying the TSV to a review document.
Result: An exact two-address cover; neither .0 nor .3 is added.
Production Snippets
An inclusive range can require two single-address blocks
text
First: 192.0.2.1
Last: 192.0.2.2
Exact cover:
192.0.2.1/32
192.0.2.2/32
Count: 2
192.0.2.0/30 would add .0 and .3 and is not an exact cover.Frequently Asked Questions
Why does an entered host address change in the CIDR?
A prefix identifies a network. Host bits are cleared when computing its canonical CIDR, while the original address is shown separately. 192.0.2.17/28 therefore starts at 192.0.2.16.
Is the last address included?
Yes. First and last bounds are inclusive. The address count is last minus first plus one; a range from 192.0.2.1 to 192.0.2.2 contains two addresses.
Why can a range need several CIDRs?
CIDRs must have power-of-two sizes and aligned starts. The .1β.2 example requires two /32 blocks. Replacing it with a /30 would add .0 and .3, so that expansion is not performed.
Why is there no broadcast label for /31?
RFC 3021 point-to-point /31 links use both addresses as endpoints without a directed broadcast address. /32 is a single address. Other subnet summaries use the traditional minus-two host model.
Does /0 or an empty slash cover everything?
An explicit /0 covers all 4294967296 IPv4 addresses. An empty slash is invalid and never defaults to /0; signs, hex prefixes and extra slash segments are rejected too.
Can these host counts be used directly for a cloud subnet?
Only after checking the provider. The tool computes mathematical ranges and traditional IPv4 reservations; cloud networks can reserve additional addresses or restrict allowed prefix lengths.
Keep browsing