Public vs Private IP Address: What’s the Difference?

01

What is a public IP address?

A public IP address is an address drawn from globally routable address space and intended for communication across the Internet. When a web server receives your request, the source address on the packets it sees is a public address somewhere along your egress path — which may or may not be an address configured on any device you own.

Public addresses come from a delegation chain. IANA allocates blocks to the Regional Internet Registries; RIRs allocate to ISPs, enterprises and other members; those organizations assign addresses to customers, sites, servers or interfaces. The address becomes reachable on the global Internet when someone announces the covering prefix into interdomain routing and other networks accept it.

A public address also does not have to be configured directly on the end host. Cloud and provider platforms can map or translate a public address to a private address behind their edge, so the Internet-facing address can belong to the connection path rather than to a local interface on the machine itself.

So the operator behind a public address might be any of the following:

• a residential or business ISP
• an enterprise with its own allocation
• a cloud provider
• a hosting or colocation provider
• a mobile carrier
• a VPN provider
• a CDN, proxy or other intermediary network

Three things are worth keeping separate here, because conflating them causes most bad conclusions about IP addresses:

1. Who holds the allocation (registry data)
2. Which network announces and routes the prefix (routing data)
3. Who was using a particular address at a particular moment (operator records)

Registry and routing data are observable from outside. The third is not. A public IP address, on its own, does not reveal a person’s identity, a street address, a specific device, or who physically used a connection. Those questions need separate context and records held by the network operator. Our IP lookup tool reports the network-level information that is actually observable, and what IP lookup can and cannot tell you covers the boundary in detail.

There is a second limit on the word “public.” A syntactically non-private address is not automatically a reachable host on the Internet. Some non-private ranges are reserved for documentation or other special purposes and should never be treated as live hosts. Others are allocated but not announced. Others are announced but filtered. Address space, routing and reachability are three separate layers.

02

What is a private IP address?

A private IP address is an address from a range set aside for use inside private internetworks. RFC 1918 defined three IPv4 blocks for this purpose, on the premise that many hosts need to communicate inside an organization without requiring globally unique addresses. RFC 1918 addresses are not intended to be globally routed as Internet source or destination addresses and should be filtered at network boundaries.

The practical consequence is that private addressing is reusable. Your home network and a hotel network on another continent can both use 192.168.1.0/24 at the same time, with a device holding 192.168.1.10 in each, and nothing breaks. Those are separate routing domains. An address only has to be unique within the context that routes it.

Private does not mean “one LAN.” RFC 1918 addresses can be routed across many subnets, sites and private WAN or VPN links. What makes them private is that they are not globally routed on the public Internet.

That reuse property is also why a private address means nothing to a remote service. If a website were somehow handed 192.168.1.20, it could not route back to you, could not distinguish your device from millions of others, and could not derive any location from it. There is nothing to look up. Trying to geolocate an RFC 1918 address is a category error, not a hard problem.

03

The three private IPv4 ranges

Valid host addresses inside those blocks look like 10.0.0.15, 172.20.5.40 and 192.168.1.25. The /8, /12 and /16 notation is CIDR prefix length — the number of leading bits that identify the block. If prefix notation is unfamiliar, RFC 4632 is the reference, and our IP address primer covers it more gently.

04

How public and private addresses work together

In a residential IPv4 network, the two kinds of address meet at a single boundary. Inside that boundary, hosts hold private addresses and talk to each other directly. Outbound traffic leaves through the gateway, and the gateway rewrites the source address so that what reaches the Internet carries a globally routable address.

Three internal devices, three private addresses, one address presented outward. Scale that to a few hundred million broadband connections and you have the reason IPv4 survived the exhaustion of its address space for as long as it did.

05

NAT, ports and the translation boundary

Network address translation rewrites address information in packet headers as they cross a boundary. The form used in nearly every home router is what RFC 2663 and RFC 3022 call NAPT — network address and port translation, also marketed as PAT. Many internal private addresses are multiplexed through one or a small number of public addresses, and the translator uses transport-layer port numbers plus per-flow state to keep the conversations apart.

A single outbound connection, using documentation addresses throughout:

The router records the address-and-port translation and related flow state in a translation table. Depending on the NAT behavior, that state may also be constrained by the remote endpoint. When the server replies to 203.0.113.42:62001, the router uses the relevant state to rewrite the destination back to 192.168.1.25:53014. Without a usable mapping, the reply would arrive at the router with no way to identify the intended internal flow.

A distinction that matters more than most readers expect: NAT is not a firewall. NAPT does have a side effect that resembles filtering, because an unsolicited inbound packet arriving at the public address usually has no matching translation entry and therefore nowhere to go. But that is an artifact of how translation state works, not a security policy. A firewall applies rules — permit, deny, stateful inspection of established flows, logging. A translator rewrites headers.

Consumer routers ship both mechanisms in one box and configure them together, which is why the two get treated as one thing. They are separate, they can be configured independently, and in IPv6 deployments the filtering usually exists without the translation.

A NAT’s mapping behavior and its inbound filtering behavior are also separate properties; one should not be used as shorthand for the other.

06

Can a private IP address reach the Internet?

Yes, indirectly. A host at 192.168.1.20 does not need a globally routed address on its own interface to load a web page. It needs a gateway that will translate or otherwise forward its traffic toward the Internet and return the replies:

device → LAN → gateway (NAT/NAPT, proxy or tunnel as applicable) → upstream network → Internet

In the common IPv4 NAT case, the host’s RFC 1918 address does not appear as the globally routed outer source address on the public Internet path. What remote systems normally see is the translated or proxy egress address. That is the mechanism behind the question nearly everyone arrives with.

07

Why your computer and an IP website show different addresses

This is the single most common confusion about IP addressing, and it has a clean explanation.

The observation. Windows shows 192.168.1.34 under ipconfig. macOS or Linux shows the same kind of address for the active interface. An IP lookup page shows something entirely different.

The mechanism. The operating system is reporting the address configured on a local interface. That is a LAN-scope address, meaningful only inside your network. The ordinary server-side HTTP connection does not expose the device’s RFC 1918 interface address; it sees the source address on the packets that arrive at the server, which is the address at the outermost translation or egress point on that path. Browser APIs can expose additional local-network signals in some circumstances, depending on browser policy and permissions.

The interpretation. Neither tool is malfunctioning. They are describing different points in the same path. There is no contradiction to resolve, and neither address is the “real” one; they are answers to different questions.

08

Public IP vs router WAN IP

The address on your router’s WAN interface and the address a website sees are often the same, and sometimes not. When they differ, at least one more translation or routing layer exists between your router and the Internet.

Comparing the two is the useful diagnostic, and it is worth stating plainly that a public address observed from outside cannot tell you by itself what sits between you and the Internet. You need both data points.

For a meaningful comparison, compare the same address family on the same active connection, refresh both readings close together, and disable or account for VPNs, explicit proxies and other policy-routing paths that intentionally change egress.

Resist collapsing these into verdicts. The middle two rows in particular are consistent with more than one architecture, and the honest reading of a private WAN address is “there is at least one more translation layer upstream,” not “you are behind CGNAT.”

09

CGNAT and the 100.64.0.0/10 shared range

What if my router does not have the public IPv4?

Then the translation to public addressing is happening somewhere upstream of your equipment. The common form is carrier-grade NAT, where the provider translates traffic from many subscribers through a pool of public IPv4 addresses.

Where 100.64.0.0/10 fits

100.64.0.0/10 is Shared Address Space, defined in RFC 6598. It covers 100.64.0.0 through 100.127.255.255, and it exists specifically to number the segment between subscriber equipment and a provider’s carrier-grade NAT.

It is not RFC 1918 private space, and calling it “another private range” gets the architecture wrong. RFC 1918 space is meant for use inside a single administrative domain, where the operator controls both ends. Shared Address Space was defined precisely because reusing RFC 1918 on the provider side collides with the RFC 1918 addressing customers already run on their own LANs. It is a distinct allocation with a distinct purpose, and it is not globally routed either.

Finding a 100.64.x.x address on your router’s WAN interface while an external service reports a different public IPv4 is a strong clue that the connection runs through carrier NAT. It is a clue rather than proof — provider architectures vary, and shared space can appear in other upstream designs — but it is the clearest single indicator available from the customer side.

What CGNAT changes in practice

• Inbound port forwarding usually stops working as expected. You can forward a port on your own router, but the carrier NAT above it has no mapping for it, so unsolicited inbound connections do not arrive.
• One public IPv4 can serve many subscribers at once. The address is shared, sometimes among dozens or more depending on the port allocation scheme.
• The public address alone no longer identifies a subscriber session. This matters for anyone reasoning about attribution. Identifying which subscriber sent a particular flow can require the public address plus the translated source port or assigned port block, the protocol, an accurate timestamp with a known timezone, and the provider’s own translation records. RFC 6302 covers why server-side logging should include source ports for this reason.
• Some peer-to-peer and hosting use cases get harder, which is why some providers offer a public IPv4 or native IPv6 service on request or for a fee.

CGNAT is not inherently insecure or malicious. It is an IPv4 address-conservation architecture, adopted as globally available IPv4 space became scarce and the RIR free pools were exhausted while demand continued. It has real operational costs — state to maintain, logging obligations, inbound limitations — and those costs are a large part of why operators deploy IPv6.

One boundary on what tools can claim, including ours: an external service that only sees your public address cannot determine on its own whether you are behind CGNAT, and cannot identify an individual subscriber sharing a carrier-NAT address. The reliable diagnostic requires comparing the externally observed address with the address on your own WAN interface, which only you can read.

10

Public and private addressing in IPv6

IPv6 does not simply repeat the IPv4 pattern with longer addresses, and the differences are the point.

In a native IPv6 deployment, a residential connection typically receives a delegated prefix, and hosts inside the network configure globally routable addresses on their own interfaces. There is no need for many-to-one translation to conserve addresses, because the address space is large enough that conservation is not the constraint it is in IPv4.

The conclusion people jump to from there is wrong. Globally routable addressing does not mean unsolicited inbound traffic is permitted. Stateful firewalling still applies. Residential IPv6 customer-edge equipment commonly provides inbound filtering that blocks unsolicited flows while permitting return traffic for connections initiated from inside; that filtering is independent of address translation. The filtering function that people credited to NAT in IPv4 is still present; it is simply doing its job explicitly rather than as a side effect of translation.

NAT in IPv6

Stating “IPv6 doesn’t use NAT” overshoots. The accurate version is that traditional consumer-style many-to-one NAPT is generally unnecessary in native IPv6 addressing, because its primary purpose — address conservation — does not apply.

Translation mechanisms do exist in IPv6 environments. NPTv6 (RFC 6296) performs stateless one-to-one prefix translation, typically for multihoming or renumbering scenarios; it is a different mechanism from stateful NAPT and does not multiplex many hosts behind one address. IPv4/IPv6 transition technologies such as NAT64 also perform translation, by necessity. What IPv6 removes is the need for address-conserving port multiplexing, not the concept of translation.

And to close the loop on a claim that circulates widely: IPv6 does not require NAT for security. NAT was never the security mechanism. Stateful filtering was, and it is available in IPv6 without translation.

11

Address scopes, and why “all IPv6 is public” is false

IPv6 has several address scopes, and only one of them is the global Internet scope.

Global unicast addresses are the globally routable scope. IANA’s currently assignable IPv6 Global Unicast Address space is 2000::/3, and most Internet-facing IPv6 addresses you encounter come from it. RFC 4291 defines the addressing architecture.

Unique local addresses (ULA) occupy fc00::/7, defined in RFC 4193. They are intended for local routing domains and are not normally routed on the global Internet. In practice, locally assigned ULAs use the fd00::/8 half of the block, with a pseudo-random global ID chosen so that independently generated prefixes are unlikely to collide when networks merge.

It is tempting to describe ULA as “the IPv6 version of RFC 1918,” and the local-addressing role is genuinely similar. The qualification matters, though: IPv6 hosts commonly hold a global address and a ULA at the same time, address selection rules govern which gets used, and ULA is not normally paired with many-to-one translation the way RFC 1918 is. The role rhymes; the operational model does not.

Link-local addresses occupy fe80::/10. They are valid only on the single link where they are configured, they are not routed anywhere, and they are fundamental to how IPv6 works — neighbor discovery, router advertisements and next-hop resolution all rely on them. An IPv6-enabled interface normally configures one. Link-local and ULA are frequently conflated, and they are not the same: link-local never leaves its link, while ULA can be routed within an organization.

One interface, several addresses

A single IPv6 interface commonly holds multiple addresses at once: a link-local address, one or more global addresses, possibly a ULA, and, depending on host policy, temporary addresses generated for privacy purposes and rotated over time. RFC 8981 specifies the temporary address extensions used with stateless address autoconfiguration.

The takeaway generalizes beyond IPv6: the idea that one device has one IP address is a simplification that stops being true almost immediately in practice. Multiple interfaces, multiple scopes, multiple simultaneous addresses per interface, and addresses that change on their own are all normal.

12

Public does not mean exposed; private does not mean secure

Two terminology problems, worth separating.

“Private” describes scope, and nothing else. A private address is not encrypted, anonymous, confidential, invisible or inherently secure. Traffic from a host at 192.168.1.25 is exactly as readable as traffic from any other host; whether it is encrypted depends on TLS or a VPN, not on the address. Within the LAN, that address is entirely visible to every other device on it.

“Public” does not mean personal information is published, and it does not mean the host is reachable. Do not write, and do not believe, that having a public IP exposes a device directly to the Internet. Public addressing makes global routing possible. Whether a given packet reaches a given service depends on:

• stateful firewall rules at the network edge
• host-based firewall policy
• provider filtering of certain ports or protocols
• cloud security groups and network ACLs
• router access control lists
• whether any service is actually listening on the port
• routing policy, including whether the prefix is announced at all

A cloud instance with a global address and a deny-by-default security group is not “exposed” in any meaningful sense. A laptop behind a home router with an unnecessary port forward to an unpatched service is exposed despite holding a private address.

13

Is a private IP safer than a public IP?

Address scope and security policy are different dimensions, and treating one as a proxy for the other is how people end up with false confidence.

A host behind IPv4 NAT usually has no direct unsolicited inbound reachability from the Internet, and that does remove one class of attack. It does not make the host secure. Compromise routinely arrives through paths that NAT does nothing about: a user clicking a phishing link, a browser or application vulnerability triggered by outbound traffic, malware arriving in a download, an already-compromised device on the same LAN moving laterally, a port forward someone configured years ago and forgot, or an inbound VPN credential that leaked.

The reverse also holds. A public-addressed host with properly configured filtering, patched services and no unnecessary listeners can have tighter exposure control than a typical home network. What matters is policy, patching and attack surface, not which range the address came from.

14

Public/private vs static/dynamic

These are independent properties, and mixing them up produces sentences that sound authoritative and mean nothing. All four combinations are ordinary:

Whether an address is stable over time says nothing about its scope, and whether it is globally routable says nothing about its stability.

15

What changes when you use a VPN?

A VPN changes the path your traffic takes to the Internet, and therefore the address remote services observe. It does not change the addressing on your LAN.

With a typical client VPN on a laptop:

• The laptop’s LAN address stays what it was, say 192.168.1.25. That underlay address remains configured and carries traffic toward the local gateway, including the tunnel itself; VPN policy may separately restrict direct access to other LAN destinations.
• The VPN client adds a virtual interface with its own address, assigned by the VPN provider.
• Traffic routed into the tunnel emerges at the provider’s exit server, and websites see that server’s address rather than your ISP-assigned one.

Saying a VPN “changes your private IP” is not right. It adds an interface and alters egress routing. Your private address remains private, remains local, and remains in use.

Split tunneling is the qualification to remember. When it is configured, only some traffic goes through the tunnel and the rest follows the normal path — which means some connections can still reveal the original egress address. The same happens with DNS requests that bypass the tunnel, or when IPv6 traffic uses a different path than IPv4. Our VPN leak test checks whether what you expect to be tunneled actually is.

16

Mobile networks

Mobile IPv4 is frequently delivered through shared addressing, with the handset receiving an address from RFC 6598 shared space or RFC 1918 space and the carrier translating to public IPv4. That pattern is common, but it is not universal, and it varies by carrier, country and plan.

IPv6 deployment is widespread in mobile networks — in several large carriers it is the primary addressing, with IPv4 provided through translation mechanisms rather than the other way around. So a phone might well hold a globally routable IPv6 address and a shared IPv4 path at the same time. Blanket statements in either direction (“all mobile users are behind CGNAT,” “mobile is all IPv6 now”) are wrong more often than they are right.

17

Public IP addresses, location and identity

A public IP address can be used as input to an IP geolocation database, which returns an estimate — typically country-level with reasonable accuracy, and progressively less reliable as the claimed precision increases. That estimate reflects registry data, operator-published information and inference, not measurement of a device’s position. It is not GPS, and it should not be read as a street address.

A private address has no globally meaningful location at all. 192.168.1.20 exists in a vast number of unrelated networks, so there is nothing to geolocate. A public IP-geolocation database cannot derive a globally meaningful location from an RFC 1918 address alone. An organization can maintain its own internal address-to-site mapping, but that is private network inventory rather than public IP geolocation.

Our IP geolocation guide covers how these estimates are produced, and why IP locations are often wrong covers the failure modes — VPNs, provider architecture, registry data that describes a headquarters rather than a customer, and shared addressing.

On identity: a public IP address is a network identifier associated with a connection along a particular path at a particular time. It does not contain a name. Under shared NAT or CGNAT, many devices and many subscribers can present the same public IPv4 simultaneously, so even mapping an address to a single subscriber line requires the operator’s translation records plus precise connection metadata. Treating an IP address as equivalent to a person is a mistake at the technical level, before any other consideration enters.

18

How to tell whether an IP address is public or private

Five steps, in order. The interpretation in step five is the part that gets skipped.

1. Read the address on the interface. On Windows, ipconfig. On macOS or Linux, ifconfig or ip addr. Note which interface is actually carrying your traffic — laptops commonly have Wi-Fi, Ethernet and virtual adapters configured at once, and a VPN adds another.
2. Compare it against the reserved ranges. Check it against Table 3 below. If it falls in 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16, it is RFC 1918 private. If it starts 169.254, DHCP probably failed. If it is IPv6 starting fe80, that is link-local. If it starts fd, that is a locally assigned ULA.
3. Check the router’s WAN address if you have access to the admin interface. This is the address your provider assigned to your equipment, and it is the data point most people never look at.
4. Check what an external service sees. An IP lookup reports the source address arriving at the server for that request path, which is the externally observed egress address for that connection.
5. Interpret the comparison. Match what you found against the diagnostic table in the router WAN section above. Equal addresses in steps three and four suggest a straightforward single-NAT path. A 100.64.x.x WAN address with a different external address points strongly at carrier NAT. An RFC 1918 WAN address tells you an upstream translation layer exists without specifying which kind. Differing public addresses have several possible explanations and need more evidence.

Special-use address quick reference

Two notes on reading that table. Loopback addresses are neither private LAN addresses nor public Internet addresses; they are a separate category, addressing the host to itself and never appearing on a wire. And 169.254.0.0/16 is IPv4 link-local, not RFC 1918 private space — a distinction that matters because the two have completely different causes. Seeing a 169.254 address on your interface is a symptom, and the usual cause is that DHCP did not answer.

The authoritative lists are the IANA IPv4 and IPv6 Special-Purpose Address Registries, which are updated as new reservations are made.

19

Common misconceptions

20

Common questions

21

Technical references

RFC 1918

Address Allocation for Private Internets

RFC 6598

IANA-Reserved IPv4 Prefix for Shared Address Space

RFC 2663

IP Network Address Translator (NAT) Terminology and Considerations

RFC 3022

Traditional IP Network Address Translator (Traditional NAT)

RFC 4787

Network Address Translation (NAT) Behavioral Requirements for Unicast UDP

RFC 6888

Common Requirements for Carrier-Grade NATs (CGNs)

RFC 6302

Logging Recommendations for Internet-Facing Servers

RFC 4291

IP Version 6 Addressing Architecture

RFC 4193

Unique Local IPv6 Unicast Addresses

RFC 8981

Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6

RFC 6296

IPv6-to-IPv6 Network Prefix Translation (NPTv6)

RFC 6092

Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service

RFC 3927

Dynamic Configuration of IPv4 Link-Local Addresses

RFC 4632

Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan

RFC 5737

IPv4 Address Blocks Reserved for Documentation

RFC 3849

IPv6 Address Prefix Reserved for Documentation

IANA

IPv4 Special-Purpose Address Registry and IPv6 Special-Purpose Address Registry