Utilisation
{{ percentUsed }}%
{{ totalAllocated }} used {{ remainingUsable }} free {{ root.usable }} total
{{ col.label }}
{{ row.hosts }} {{ row.cidr }} {{ row.network }} {{ row.first }} {{ row.last }} {{ row.broadcast }} {{ row.notes }}
auto auto auto auto auto
{{ col.label }} Copy
No allocations yet.
{{ row[col.key] }} 

        

      


    

  


  

    

      

        
{{ toastMessage }}

        
      

    

  

                

                

                    

                        

                            Tags:
                                                            
                                    IP Addressing
                                
                                ,                                                             
                                    Networking
                                
                                ,                                                             
                                    Sysadmin
                                
                                                                                    

                        

                            Export to PDF
                            Fullscreen
                        

                    

                

            

        

    


        
    

        

        

            


                

                    

                    
                


                

                

                
            

            

                
                
            

        

    


    

        

                                                                                                                                                                                                                                                                        
        

            

                
                
                
                
            

            

                
                
            

            

                

                    

                        

                            
                            
                        

                    

                    

                        

                            
                            
                        

                    

                    

                        

                            
                            
                        

                    

                    

                        

                            
                            
                        

                    

                    

                        
                        
                    

                    

                        
                        

                            
                            
                        

                    

                    

                        
                        

                            
                            
                        

                    

                    

                        
                        

                            
                            :
                            
                        

                    

                    

                        
                        

                            
                            
                        

                    

                    

                        
                        
                    

                    

                        
                        
                    

                    

                        

                            
                            
                        

                    

                    

                        
                        
                    

                    

                        
                        
                    

                

            


            
        

    



    

        

  
  
IPv4 allocation work is mostly about boundaries, not just counting devices. A network can look large enough on paper and still fail once every subnet has to start on the right binary boundary and expand in powers of two. That is why early planning choices often decide whether a rollout stays tidy or turns into avoidable renumbering later.

  
This page turns a parent CIDR block into a working subnet plan. You enter the root network and prefix, add host demands one row at a time, and the result shows the derived CIDR range, network address, first usable address, last usable address, broadcast address, notes, and remaining usable capacity for the whole plan.

  

    Example IPv4 planning flow that turns host requests into aligned subnets inside one parent block.
    
The host counts you enter are requests. The actual rows are the smallest aligned subnets that can carry those requests.

  

  
It is most useful when you already know the rough demand for each VLAN, site segment, lab network, transit link, or reserved slice and need a plan you can hand to someone else without redoing the binary math by hand. The page allocates forward from the highest address already used, so the order in which you enter requests becomes part of the result.

  
The calculations stay in the browser. That reduces exposure, but copied tables, downloaded files, and the notes field can still reveal internal addressing plans, so saved output should be treated like any other infrastructure document.

  
The result is still only subnet math. It does not decide whether a range should be private-use, documentation-only, publicly routed, or kept out of production entirely, and it does not check what your provider, firewall policy, or summarization design will accept.






  
Technical Details

  
The page treats each IPv4 address as an unsigned 32-bit value. After you enter a root address and choose a prefix from /8 through /31, it masks the address to the canonical network boundary, then derives the root network, broadcast address, first usable address, last usable address, and usable-host count from that normalized parent block.

  
Each new host request is converted to the smallest subnet that can honestly carry it. For demands of three or more hosts, the page adds two addresses for the traditional network and broadcast positions, rounds up to the next power of two, and converts that size back into a prefix length. A two-host request is handled as a /31, matching RFC 3021 point-to-point practice, while a one-host request becomes a /32.


  
The sizing and alignment rules are the core of the calculation.

  

    
      
        
          M
          =
          
            
              {
              
                1if H<=1
                2if H=2
                H+2if H>=3
              
            
          
        
        
          b
          =
          ⌈log2M⌉
        
        
          S
          =
          2b
        
        
          p
          =
          32-b
        
        
          A
          =
          R+⌈N-RS⌉×S
        
      
    
  

  
The first four lines size the subnet. The last line aligns the next start address to the nearest legal boundary inside the parent block, which is why a request can fail even when the raw remainder still looks positive.


  

    

      
      
        

          Symbol
          Meaning here
          How to read it in practice
        

      
      
        

          H
          Requested host count
          The demand you enter in the new row.
        

        

          M
          Minimum addresses needed before rounding
          Three or more hosts add two extra positions for the usual network and broadcast roles.
        

        

          S
          Total addresses in the derived subnet
          This is always a power of two such as 8, 16, 32, or 64.
        

        

          p
          Resulting prefix length
          A larger subnet size means a shorter prefix such as /26 instead of /27.
        

        

          R, N, A
          Root start, next candidate start, aligned start
          The page moves to the next legal start inside the parent block instead of placing a subnet on an arbitrary address.
        

      
    

  


  

    

      
      
        

          Step
          Value for 60 hosts
          Why it changes
        

      
      
        

          Requested demand
          H = 60
          The row starts with the number you type.
        

        

          Need before rounding
          M = 62
          Two addresses are added for the usual network and broadcast positions.
        

        

          Rounded block size
          S = 64
          Sixty-two must round up to the next power of two.
        

        

          Derived prefix
          p = /26
          Sixty-four total addresses map to a /26.
        

        

          Usable count shown by the page
          62
          The summary and chart use usable capacity for the derived block, not just the original request.
        

      
    

  


  

    

      
      
        

          Behavior
          What the page does
          Why it matters
        

      
      
        

          Root normalization
          An entry such as 10.0.0.7 with /24 is normalized to the 10.0.0.0/24 network before planning begins.
          You always plan from the canonical network boundary, not the host address that happened to be typed.
        

        

          Forward-only allocation
          Each new row starts after the highest broadcast address already allocated, then aligns to the next legal boundary for that subnet size.
          Deleting an early row does not repack later rows. If the order changes, the cleanest fix is usually to rebuild the plan.
        

        

          Usable-capacity accounting
          The summary badges and utilization percentage add the usable capacity of derived subnets, not the raw host demands you typed.
          A request for 60 hosts consumes 62 usable addresses once it becomes a /26.
        

        

          Visible-column exports
          The allocation table, CSV copy, CSV download, DOCX export, and JSON output all follow the columns that are currently visible.
          Hiding Network or Broadcast removes those fields from the exported result too.
        

        

          Filter-aware detail views
          The table view, JSON tab, and host-share chart follow the current filter text, while the summary box still reflects the full allocation list.
          A narrow filtered view is useful for sharing one slice of the plan, but the top summary still reports whole-plan usage.
        

        

          Browser-only processing
          Calculation, chart rendering, copying, and downloads happen in the browser, with no server helper for this tool.
          Network details are not sent away by the tool itself, but saved outputs can still expose your design.
        

      
    

  






  
Everyday Use & Decision Guide

  
The safest habit is to enter the largest segments first. Bigger subnets have stricter alignment needs, so adding them early reduces the chance that a later request is pushed onto a larger boundary or forced out of the parent block entirely.

  
This page is strongest when the question is operational. You know roughly how many addresses a user VLAN, printer segment, management network, wireless pool, lab slice, or point-to-point link should have, and you want a clean worksheet that shows where each block begins and ends. The notes field helps with naming, but it is only a label. It does not change the math.

  
For design drafts, examples, and ticket discussion, it is often smarter to work with documentation prefixes such as 192.0.2.0/24, 198.51.100.0/24, or 203.0.113.0/24 until the production range is approved. That keeps the math realistic without exposing a live addressing plan unnecessarily.

  
    
    
  • Plan for peak demand plus modest growth, not just the devices connected today.
    • 
    
  • Reserve narrow segments such as transit links, loopback-style placeholders, or management islands explicitly instead of assuming they will fit later.
    • 
    
  • Use /31 only when the link really is point-to-point and both ends support that design.
    • 
    
  • Rebuild from the top if a large early segment changes, because later rows are not compacted automatically.
    • 
    
  • Check special-purpose status and routing policy separately before treating a mathematically valid plan as deployable.
    • 
  






  
Step-by-Step Guide

  
    
    
  1. Enter the parent network address in dotted-decimal form, then choose the root prefix.
    2. 
    
  2. Confirm that the root block shown by the summary matches the network you intended after normalization.
    3. 
    
  3. Add the largest host demand first, then continue downward with smaller segments as the plan takes shape.
    4. 
    
  4. Use the notes field to mark the purpose of each row, such as users, voice, printers, transit, or staging.
    5. 
    
  5. Toggle columns to match the audience, then use the Allocation Table, Host Share Chart, and JSON tabs for copy or download actions.
    6. 
    
  6. If a row fails with Not enough space for that subnet, try a larger parent block, reduce the request, or clear the list and reorder the allocations.
    7. 
  






  
Interpreting Results

  
The summary box at the top is about usable capacity, not the exact demand numbers you typed. If you ask for 60 hosts and the page derives a /26, the plan counts 62 usable addresses as consumed because that is the real space taken by the subnet. The used, remaining, and utilization values all follow that rule.

  
Each row tells a slightly different part of the story. Hosts is the requested demand. CIDR is the real block size needed to satisfy that demand. Network, First IP, Last IP, and Broadcast show the operational boundaries that matter when you document interfaces, DHCP pools, static reservations, or ACL ranges.

  
The Host Share Chart is a capacity view. It compares the usable size of each currently filtered subnet and adds an Unallocated hosts slice for what remains inside the root block. The JSON tab and table exports follow the filtered rows and the visible columns, so they are good for sharing one slice of the design. The top summary does not shrink with that filter, which helps preserve whole-plan context.

  
Read the error message carefully too. Not enough space for that subnet means the aligned block would extend past the parent network. That can happen because the root really is full, because an earlier large segment consumed more capacity than the raw demand suggests, or because a deleted gap is no longer reused automatically.

  
A successful allocation row is not the same thing as a production-ready decision. Before deployment, check whether the chosen range is appropriate for private use, documentation, benchmarking, or public routing, and confirm that the prefix length matches the equipment and policies involved.






  
Worked Examples

  
The examples below use documentation prefixes reserved for examples and training material, so they illustrate the math without pointing at a live network.


  
Branch VLAN Plan From One /24

  
Start with 198.51.100.0/24. A request for 60 hosts becomes 198.51.100.0/26, which provides 62 usable addresses. A second request for 20 hosts becomes 198.51.100.64/27, and a third request for 6 hosts becomes 198.51.100.96/29. The remaining portion of the /24 is still available for later rows, but every new request must begin at the next legal boundary after the last allocated broadcast address.


  
Two-Address Link Planning

  
Start with 203.0.113.0/29 and request 2 hosts. The page derives 203.0.113.0/31 and counts both addresses as usable. That is correct for a point-to-point link under RFC 3021, but it is not the right choice for a general LAN where broadcast behavior still matters.


  
Why Deleting A Row Does Not Reopen Earlier Space

  
Start with 192.0.2.0/26. First request 20 hosts, which becomes 192.0.2.0/27. Then request 3 hosts, which becomes 192.0.2.32/29. If you delete the first /27 and request 20 hosts again, the page does not jump back to the freed space at the front. It still tries to allocate after 192.0.2.39, aligns the next 20-host request to the next /27 boundary, and fails because that boundary falls outside the parent block. That behavior is consistent with a forward planning worksheet rather than a compaction engine.






  
FAQ


  

    Why does a 60-host request count as 62 used in the summary?
    
Because the page measures consumed usable capacity after the request is converted into a real subnet. Sixty hosts require a /26, and a /26 has 62 usable IPv4 addresses under the page's standard host-count rule.

  


  

    Why can the chart and JSON change after filtering while the top summary stays the same?
    
The filter narrows the detailed views so you can focus on matching rows. The summary box still reports whole-plan usage from the full allocation list, which keeps the overall capacity picture visible even when the detail views are narrowed.

  


  

    Can I use this for /31 links and /32 single-address reservations?
    
Yes. A two-host request becomes a /31, and a one-host request becomes a /32. That is useful for point-to-point links, loopback-style entries, or single-address placeholders, as long as the network design really calls for those edge cases.

  


  

    Does the page warn if I choose a private, documentation, loopback, or other special range?
    
No. It validates subnet structure and alignment, but it does not classify the parent block against RFC 1918 space, documentation prefixes, link-local space, loopback ranges, benchmarking space, or other special-purpose assignments.

  


  

    Does any data leave the browser when I use it?
    
The tool itself does not rely on a server helper for calculation or export generation. The main exposure comes from what you copy, download, save, or paste elsewhere after the result is generated.

  






  
Glossary

  

    
CIDR

    
Prefix notation that defines an IPv4 block by its network boundary and size.


    
Parent Block

    
The root network from which every planned subnet is carved.


    
Aligned Boundary

    
A legal starting address for a subnet of a given size inside the parent block.


    
Usable Hosts

    
The addresses the page counts as assignable within the derived subnet.


    
Broadcast Address

    
The last address in most IPv4 subnets, traditionally reserved for all-host delivery.


    
Point-to-Point /31

    
A two-address subnet style commonly used for router-to-router links where both addresses can be treated as usable.

  






  
References