$ run IPv4 Calculator
NetCalc by Alexmysterio — Mobile app coming soon · Telegram bot available

Enter runs the calculation · Shift+Enter inserts a new line

user@netcalc ~/calc $

ipv4_calculator

Calculate network, broadcast, mask, hosts, class and binary for any IPv4 address

ip:
mask:
user@netcalc ~/calc $

ipv6_calculator

Calculate network info for IPv6 addresses in CIDR notation

ipv6:
pfx:
user@netcalc ~/calc $

vlsm_calculator

Variable Length Subnet Mask — assigns optimal blocks for each network segment

net:
pfx:
// Subnets required
name:
hosts:
name:
hosts:
name:
hosts:
user@netcalc ~/calc $

usable_ip_range

Shows the exact usable host range for a given network

ip:
mask:
user@netcalc ~/calc $

binary_ip_calc

Convert IP addresses to binary and vice versa, with per-octet visualization

dec:
bin:
user@netcalc ~/network $

cidr_converter

Convert between CIDR, decimal mask and wildcard. Includes full /1–/32 reference table.

in:
📋 CIDR Reference Table
CIDRSubnet MaskWildcardHosts/24 subnetsBlock
user@netcalc ~/network $

wildcard_mask_calc

Calculate the wildcard (inverse) mask for Cisco ACLs, OSPF and firewall rules

mask:
user@netcalc ~/network $

supernet_calculator

Find the minimum supernet containing all specified networks (route summarization)

nets:
user@netcalc ~/network $

subnet_splitter

Split a network into equal subnets by specifying a new prefix

net:
mask:
new:
user@netcalc ~/network $

range_to_cidr

Convert an IP range (start–end) to the minimum set of CIDR blocks

start:
end:
user@netcalc ~/network $

ip_to_integer

Convert IPv4/IPv6 addresses to integer and vice versa

ip:
int:
user@netcalc ~/network $

ipv6_normalize

Expand and compress IPv6 addresses — normalize any valid format

ipv6:
user@netcalc ~/network $

hex_ip_converter

Convert between hexadecimal and IP address — useful for Windows route tables and Cisco logs

ip:
0x:
user@netcalc ~/network $

vlan_calculator

802.1Q VLAN info: tag encoding, PCP, DEI, VID, range and compatibility

vlan:
pcp:
dei:
user@netcalc ~/dns $

reverse_dns_generator

Generate the PTR in-addr.arpa zone for an IPv4 network

net:
pfx:
dom:
user@netcalc ~/dns $

ipv6_ptr_generator

Generate the PTR ip6.arpa record for an IPv6 address

ipv6:
host:
user@netcalc ~/dns $

ip_geolocation

Locate a public IP or resolve a domain and geolocate its public address

Domains are resolved through DNS first; geolocation is based on the resulting public IP.
geo:
user@netcalc ~/dns $

ip_address_planner

Interactive IP address space planner — click cells to edit, export to CSV

📋 IP Address Plan
#NameNetworkMask/CIDRGatewayVLANLocationNotes
user@netcalc ~/legal $

Privacy

Data stored in your browser

Theme, language, promotion dismissal and calculation history are stored in localStorage on this device.

Calculations

Calculations are sent through this site's same-origin Worker proxy to the private calculation service.

Performance metrics

LCP, CLS and INP may be stored as aggregate performance measurements by tool and language. Calculation inputs and persistent user identifiers are not included.

GeoIP

Only GeoIP lookups are processed by an external provider. The requested IP address is sent for that lookup.

Issue reports via Telegram

A report link opens the public Telegram bot and includes only the current page slug in the bot start parameter. Calculator inputs and report text are not sent by this website. Text you choose to send inside Telegram is handled by Telegram and the bot.

Cookies and advertising

Advertising is controlled by the production configuration. When Google AdSense is enabled, consent is handled through a certified CMP before personalized advertising is used where required.

Delete local data

Use the button below to clear calculation history. To remove every local preference, clear this site's data in your browser settings.

This page provides operational information; it is not a legal-compliance certification.

RDAP vs ASN vs GeoIP: what each lookup actually tells you

Separate registration, routing ownership, DNS and approximate location so network investigations use the right evidence.

By 2026-09-21≈ 6 min7 sections
IP or domain DNSresolutionA / AAAA / PTR ASNroute originBGP context RDAPregistrationRIR / handle GeoIPestimatenot identity Combine evidence; no single source answers every question
What each data source answers in an IP or domain investigation
01

RDAP answers registration questions

RDAP is about registered resources: an IP network, autonomous system or domain, its handle, status, events and associated entities. It is authoritative for allocation context when you query the correct registry.

02

ASN data answers routing-ownership questions

An ASN lookup helps identify the network that originates or is associated with a public address. That is useful for routing context, but the ASN is not the same thing as the website owner or the physical location of a user.

03

GeoIP is an estimate

Geolocation providers infer country, region or city from routing and commercial datasets. The result can be useful for broad context while being wrong at city level, especially with mobile networks, VPNs, CDNs and anycast.

04

DNS provides another independent layer

A domain name can resolve to infrastructure operated by a CDN or hosting provider. Combining DNS, ASN and RDAP gives stronger context than treating any one lookup as a complete identity source.

05

Build a chain of evidence instead of one “owner” field

A useful investigation records what each source actually claims. DNS says where a name resolves, ASN data says who originates a route, RDAP says how an Internet resource is registered and GeoIP estimates location. These facts can point to different organizations without contradicting each other.

06

Expect CDN, anycast and cloud abstraction

A single hostname may return different addresses by region, while one anycast address is announced from many physical sites. Cloud customers can also use provider-owned prefixes. This is why ASN or RDAP ownership should not be presented as proof of website ownership or user location.

07

Record time and source when results matter

Routing, DNS and registration data change. For troubleshooting or incident notes, record the query, timestamp and data source so somebody can reproduce the observation later instead of treating a transient lookup as permanent truth.

EX

Worked example

  1. Resolve example.com and note every returned A/AAAA address rather than only the first.
  2. Check the ASN for the selected public address to understand route origination.
  3. Query RDAP to identify the registered network block and allocation context.
  4. Use GeoIP only as approximate context and record that it may reflect a POP, carrier or provider rather than the end user.
✓

Operational checklist

  • Keep DNS, ASN, RDAP and GeoIP as separate evidence fields.
  • Record the exact queried IP or domain and timestamp.
  • Expect CDN/anycast results to vary by resolver and location.
  • Never treat GeoIP city data as precise physical location.

Standards and references