A surprising number of “the firewall is broken” tickets are actually “the address in the rule is from a reserved range and was never going to route.” Someone allowlists 172.32.0.5 thinking it’s RFC 1918 (it isn’t — that’s outside the private range), or types 169.254.10.5 and wonders why packets never leave the local segment (link-local doesn’t egress). The PortJar Public / Private IP Checker categorises an address against the registries in one paste, so the conversation moves from “is this private?” to “here’s the actual fix.”
What the tool does
Paste any IPv4 address and the checker reports which class of space the address belongs to: public (globally routable), private per RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), loopback (127.0.0.0/8), link-local (169.254.0.0/16), shared address space for carrier-grade NAT (100.64.0.0/10), multicast, documentation prefixes, or various reserved blocks. The classification runs entirely in the browser against the IANA special-purpose registry; nothing leaves the page.
The output names the specific block the address lives in, not just the category. That extra detail is the part that prevents the second-most-common mistake — confusing RFC 1918 with the broader “anything that isn’t public” bucket. A documentation prefix like 192.0.2.0/24 is reserved, but it is not RFC 1918, and treating it as private will lead you down the wrong remediation path.
How to use it
Open portjar.com/tools/ip-classifier, paste the address, and read the classification. There is nothing to submit and no network call. If you are auditing a list of addresses, run them one at a time — the output is short enough that copying each result into a spreadsheet takes seconds.
For batch work on a long list, the checker is the wrong shape; reach for a script. But for the one or two surprising addresses that fall out of a log review or a firewall audit, this is the fastest way to settle the question.
When you’d reach for it
- Firewall rule audits. A list of allowlisted addresses contains an entry that “looks private.” The checker tells you whether it actually is — and which RFC 1918 block, or whether it’s a documentation prefix that should never have been in the rule.
- NAT troubleshooting. A client reports that traffic from their office is showing up at your edge as
100.78.4.12. That’s not RFC 1918 — it’s carrier-grade NAT shared space, which means their ISP is doing CGNAT and the address can be reused by another subscriber tomorrow. - Log triage. A SIEM alert fires on connections “from
169.254.169.254.” That’s not a real client — it’s the link-local address most cloud providers use for the instance metadata service. The alert is misconfigured, not the network. - Documentation hygiene. A vendor’s docs use
203.0.113.5in an example. The checker confirms that’s the IPv4 documentation range and the address won’t conflict with anything real — so you can leave it in a runbook without worrying about future overlap. - DHCP misconfiguration diagnosis. A workstation is reporting an address starting with
169.254.. That is APIPA — the OS gave up on DHCP. The fix is upstream, not on the client.
What to make of the output
A “public” verdict means the address is in space the registries allocate to operators; it should reach the internet, and the rest of the internet should be able to reach it (modulo firewalls). A “private” verdict — specifically RFC 1918 — means the address should never appear as a source on the public internet, and if it does, something between the client and the destination is misconfigured or actively trying to obscure the origin.
The grey-area verdicts are the interesting ones. Carrier-grade NAT space (100.64.0.0/10) looks public but isn’t routable on the public internet — it’s the address pool ISPs use behind their own NAT. Link-local (169.254.0.0/16) is a self-assigned fallback when DHCP fails. Documentation ranges (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24) exist so technical writing can use a real-looking address without colliding with production traffic anywhere. Any of those showing up in a production allowlist is almost always a typo.
A blank result means the input wasn’t a valid IPv4 — usually a stray character, an IPv6 address pasted in, or a hostname instead of a numeric address.
For environments where source-address policies, NAT egress, and firewall rules need to stay correct as networks change, Stack Harbor handles the classification discipline as part of environment management.