Public vs private IP addresses

Why your device settings and an IP-checking website can show different addresses, and which one to use.

Published:

Where a private IP fits into a connection

A private IP address is used inside a local network, while a public address participates in globally managed internet address space. Your laptop can have a private IP on Wi-Fi while a website sees the public address of your router or provider gateway. Both observations can be correct. The difference describes where the address is used, not which tool is necessarily more accurate.

Start by deciding which side of the connection matters. If you are connecting a printer, configuring a local file share, or checking your router's gateway, a private IP may be the relevant value. If a remote service asks which source it sees, you usually need the public observation from the homepage. Copying a local interface value into a public allowlist can fail because the remote service never sees that value.

Reserved IPv4 ranges

The IPv4 private ranges are 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. They are defined for internal use and can be reused independently in different networks. A private IP in one household does not identify the same device as an identical value in another household. No public registry can tell which of those independent local assignments you intended simply from the number.

Be careful with the 172 range. Not every address beginning with 172 is private. The specified block runs from 172.16.0.0 through 172.31.255.255. Likewise, a familiar-looking address should be checked against its actual range rather than classified by the first few digits alone. The IP lookup tool can classify a private IP locally without making a false subscriber lookup.

How local devices connect to public services

A typical home router gives local devices addresses through DHCP and translates outbound IPv4 connections through NAT. The router keeps state that lets returning traffic reach the correct internal connection. Several devices can therefore share one public source. A private IP remains useful inside the household, while the public observation describes the exit seen by the destination.

This does not mean NAT is a complete security policy. Firewalls, exposed services, router configuration, and application security still matter. A private IP is a scope and addressing concept, not a guarantee that every service behind the router is protected. Devices on the same local network may still communicate, and a compromised local device can create risks that an external address check cannot assess.

CGNAT is a separate shared range

Carrier-grade NAT lets a provider share public IPv4 addresses across customers. The designated shared address range is 100.64.0.0/10, from 100.64.0.0 through 100.127.255.255. It is distinct from the RFC 1918 private IP ranges. A router's WAN value in this range is useful evidence to discuss with the provider when you are investigating incoming connection restrictions.

Do not confuse a private IP shown on the router's LAN side with its WAN address. The LAN gateway is expected to be local. The WAN status describes the connection toward the provider. Comparing the correct WAN value with the observed public address can help identify upstream translation, but a full diagnosis should also consider proxies, VPNs, and the provider's documented service architecture.

IPv6 has different scope concepts

IPv6 can give devices globally scoped addresses without the same household NAT pattern used by IPv4. It also defines local scopes. Unique local addresses fall within fc00::/7, with locally assigned examples commonly beginning with fd. Link-local addresses use fe80::/10 and serve communication on a link. These are related to local networking, but calling every non-public IPv6 value a private IP can hide useful distinctions.

A device can hold several IPv6 addresses at once, including temporary global values and link-local values. The address used for a browser request depends on its route and source selection. A private IP check cannot inventory that entire interface state. Open the device's network settings when you need the address and scope of a specific interface, and use a browser test for the browser's observed public path.

Choose the right value for the task

For a local printer or file share, inspect the active adapter and the local service configuration. The relevant private IP may change after a DHCP lease change, so a reservation or appropriate local name can be preferable for a stable setup. Do not change the entire router subnet merely because one device has moved within the existing range. First understand how that device receives its assignment.

For remote access, a private IP alone is normally insufficient from another independent network. You need an authorized path such as a properly configured VPN, a managed access service, or an appropriate public service arrangement. Port forwarding is only one mechanism and can be blocked by upstream translation. Exposing an administrative interface to the internet is not a harmless substitute for understanding the path.

For a support allowlist, ask what the remote system actually observes. A public IPv4 address shared by a household or provider has different implications from one globally scoped IPv6 address. A private IP can identify a local device but cannot serve as a universally unique internet identity. Use the narrowest appropriate rule and remember that dynamic assignments can change the value later.

Common classification mistakes

An address beginning with 127 is loopback, not an ordinary private IP assignment on your Wi-Fi network. IPv4 link-local addresses in 169.254.0.0/16 also have a different role. Documentation ranges such as 192.0.2.0/24 are reserved for examples. Grouping all unfamiliar or non-public values together can lead to an incorrect fix, so preserve the actual category in a support report.

Two devices reporting the same private IP can be normal if they are on separate networks. The same duplicate within one active subnet can cause a conflict. Before changing an address, identify the interface, subnet, DHCP server, and intended assignment. A screenshot that omits those details does not establish whether there is a collision or merely reuse across unrelated local networks.

VPN connections can add another local interface and another address range. A work application may use that tunnel while ordinary browsing exits elsewhere. The private IP shown for the tunnel does not necessarily replace the Wi-Fi interface's address. Compare the route used by the specific application and destination. One browser page cannot determine the policy of every application on the device.

Overlapping networks and VPNs

Private IP reuse becomes troublesome when independently configured networks need to communicate. Two offices can both use 192.168.1.0/24 without problems until a VPN attempts to join them. The routes then need a clear way to distinguish destinations. A subnet calculator can verify overlap boundaries, but resolving the design requires an inventory and a careful change plan.

Do not renumber production networks without considering static devices, DHCP reservations, DNS, firewall rules, monitoring, and remote access. A private IP range is embedded in more places than a router's single settings page. Record the existing configuration, test a controlled change, and preserve a recovery path. Address arithmetic is useful evidence for the plan, not a replacement for operational preparation.

Document a local connection problem

Write down the local interface address, its prefix, the default gateway, the router's WAN value where available, and the browser's public observation. Keep each label attached to its value. A private IP and a public address answer different questions, so comparing them without their roles can be misleading. Include the observation time and VPN state if you share the results with support.

The IPv4 private IP ranges are specified in RFC 1918, shared carrier space in RFC 6598, and unique local IPv6 addresses in RFC 4193. Continue with IPv4 vs IPv6 or static vs dynamic IP to understand how protocol choice and assignment stability add separate dimensions to the local-versus-public distinction.

Public vs private IP addresses — common questions

Is every IPv4 address beginning with 172 private-use space?

No. The reserved private block spans 172.16.0.0 through 172.31.255.255. Check the actual range instead of classifying an address only by its first decimal part.

Does a private local assignment mean that my internet connection is broken?

No. It is expected on many home and office networks that translate outbound traffic. A local value and the public exit answer different questions; test the intended connection before drawing a failure conclusion.

Is 100.64.0.0/10 one of the ordinary private IPv4 ranges?

It is separately reserved shared address space associated with carrier use. Keep it distinct from the private LAN blocks, especially when comparing a router's upstream field with a public browser observation.

Can two companies' identical local ranges cause VPN problems?

Overlapping ranges can make destination selection ambiguous for the required routes. Document both sides and involve the responsible administrator; simply recognizing a private range does not determine the correct configuration change.

Does IPv6 use the same private-range rules as dotted IPv4?

No. IPv6 has its own address scopes and reserved ranges. A colon-separated value needs family-appropriate interpretation rather than an IPv4 rule based on familiar decimal prefixes.

Can I submit a local printer address to an internet service's allowlist?

It usually will not describe the source the remote service receives. Confirm the intended side of the connection and destination's requirements instead of substituting a familiar local assignment for the observed exit.

Why can a local device have internet access but fail to reach a guest-network printer?

Working outbound access does not guarantee communication across isolated segments. Compare the network, routes, and relevant policy for the local task; a valid private assignment alone is not proof of mutual reachability.

Does a globally scoped interface listing prove unrestricted public access?

No. Display scope, actual routing, firewall policy, and successful service connections are separate observations. Keep the interface context and test results rather than interpreting one label as a guarantee of inbound access.