Public IP Snapshot
{{ result.ip }}
{{ summarySecondaryLine }}
{{ scopeBadgeText }} {{ result.type }} {{ familyBadgeText }} {{ agreementBadgeText }} AS{{ result.connection.asn }} Local: {{ localTimeShort }}
Public IP lookup inputs
{{ inputHelperText }}
Options: Auto, IPv4 first, or IPv6 first; manual IP entries ignore this setting.
Consensus fills the source ledger and map; Fastest successful favors speed over agreement evidence.
On queries public DNS-over-HTTPS for one PTR hostname when published.
{{ ptrLookupEnabled ? 'On' : 'Off' }}
Field Value Copy
{{ row.label }} {{ row.value }}
No source consensus chart available
Provider enrichment was unavailable for this lookup, so there is no consensus chart to draw.
Source Coverage Location Timezone ASN Coords Operator Copy
{{ row.label }} {{ row.coverage }} {{ row.location }} {{ row.timezone }} {{ row.asn }} {{ row.coords }} {{ row.operator }}
No provider ledger available
Run a consensus lookup with successful provider enrichment before exporting this ledger.
Open OSM Open Google
No location drift map available
No successful provider returned map coordinates for this IP.
Section Signal Detail Copy
Recommended next check {{ note.title }} {{ note.body }}
Current route note {{ row.label }} {{ row.value }}

                
Customize
Advanced
:

Introduction

A public IP address is the outward-facing address that websites, mail servers, VPN gateways, and other remote systems see when your traffic leaves the local network. It is different from the private address inside a home or office LAN, and it usually reflects the network exit point rather than the device itself.

This checker can detect the current browser's public route or inspect a specific globally reachable IPv4 or IPv6 address that you enter manually. It returns the chosen IP, address scope, address family, current IPv4 and IPv6 paths when available, ASN and operator details, country and city labels, timezone and local clock, optional reverse-DNS hostname, source agreement, map coordinates, and exportable snapshot files.

That combination is useful when a VPN exit looks wrong, a firewall team needs the exact address and ASN for an allowlist, or a support engineer needs to explain why a connection appears to come from a different city than the user expects. The page is strongest when you read the network identity fields together rather than trusting a single place name on its own.

Location labels need restraint. IP geolocation is inherently imprecise, and different data providers can map the same route to different metro areas or coordinate pairs. City, postal code, and the map marker are best treated as routing context, not as proof of a person's exact physical location.

The work happens in the browser, but the lookup does not stay entirely local. A blank run contacts public IP discovery services, enrichment requests go to public IP data providers, PTR lookups go to public DNS-over-HTTPS resolvers, map tiles load only when the map tab opens, and the current settings are mirrored in the page address for easy reruns and sharing. The page itself does not build a cookie, local-storage, or session-storage history of your checks.

Browser route Blank = detect now Manual = inspect target IP Current paths IPv4 and IPv6 probes Enrichment IP data + PTR lookup Result tabs Routing Snapshot Source Consensus Map, Next Checks, JSON
The page first decides which public address to inspect, then enriches that address with provider data and optional PTR results before building the copy-ready snapshot, agreement view, map, guidance, and JSON export.

Technical Details

Blank input triggers two discovery checks: one for the current public IPv4 path and one for the current public IPv6 path. The Preferred family control decides which family is inspected first when both are present. Manual mode skips auto-selection and inspects the address you entered instead, but only if it is a globally routable public IP.

The page rejects addresses that are not suitable as public route targets before enrichment begins. That includes IPv4 private ranges, carrier-grade NAT space, loopback, link-local, documentation and benchmarking ranges, as well as IPv6 unique-local, loopback, link-local, documentation, multicast, and unspecified ranges. That guardrail prevents a local-only address from being mistaken for an outward-facing route.

After a target is chosen, the checker queries the two shipped enrichment sources and normalizes both replies into one common record shape. In Consensus cross-check mode it keeps all successful replies, compares them field by field, and chooses the most common display value for country, region, city, timezone, operator, and ASN. In Fastest successful mode it stops at the first usable enrichment reply, which is quicker but gives less evidence about disagreement between providers.

The chosen coordinates come from the richest successful provider payload. The page then measures how far the other successful coordinates drift from that chosen point and reports the largest spread in kilometers. If Reverse DNS lookup is enabled, the checker builds the appropriate in-addr.arpa or ip6.arpa name and asks public DNS-over-HTTPS resolvers for a PTR answer.

Agreement(field) = aligned sourcessources reporting that field Spreadkmmax = largest great-circle distance from the chosen coordinates to every other reported coordinate Consensus label = strong if average field alignment is at least 0.84, mixed if at least 0.50, single if one source replied, detected path only if none replied
Lookup rules used by the public IP checker
Lookup rule Shipped behavior Why it matters
Blank input Detects current public IPv4 and IPv6 paths, then chooses the target according to the preferred family. Useful when you want to know how the present browser session looks from the outside.
Manual input Accepts only globally reachable IPv4 or IPv6 addresses. Prevents private, loopback, and example ranges from being treated as real public routes.
Consensus cross-check Queries both enrichment sources and keeps the agreement ledger, alignment ratios, and multi-marker map behavior meaningful. Best when trust and explanation matter more than shaving off one request.
Fastest successful Stops after the first usable enrichment reply. Best for a quick spot check when you do not need to compare source disagreement.
Reverse DNS enabled Attempts a PTR lookup and adds the hostname when a resolver returns one. A hostname can help explain CDN edges, mail paths, or provider ownership, but blank PTR is normal.
Exports Builds CSV, DOCX, chart files, and JSON in the browser from the normalized result. Keeps the shared evidence aligned with the exact values you reviewed.

Privacy limits follow the same boundary. The page does not use a site-side helper for scoring or storage here, but the checked IP, optional manual target, and related settings can still appear in the URL query string and in exported files. If that is too visible for the task, use the page only on non-sensitive public addresses and avoid sharing the result URL directly.

Everyday Use & Decision Guide

Start with a blank input when the question is "How does this browser look right now?" Use manual input when the question is "What does this exact public IP look like?" If you expect dual-stack behavior, leave the field blank first so you can see whether the current session exposes both an IPv4 and an IPv6 path before you narrow the check to one family.

The main decision fork is speed versus evidence. Consensus cross-check is the better default for troubleshooting because it gives you agreement counts, a provider ledger, and a more meaningful drift map. Fastest successful is fine when you only need one quick answer, but it cannot tell you whether another source would have disagreed on the city, timezone, or operator.

  • Open Routing Snapshot when you need the copy-ready details table, CSV copy or download, and DOCX export.
  • Open Source Consensus when you want to see how well the sources agree on address, country, city, timezone, operator, coordinates, and PTR.
  • Open Location Drift Map when you want to compare returned coordinates visually and open the chosen point in OpenStreetMap or Google Maps.
  • Open Next Checks when you need a quick explanation of what to verify next for support, allowlisting, or VPN troubleshooting.
  • Open JSON when another system or teammate needs the normalized payload exactly as the page built it.

Read the result in layers. Start with the checked IP, address scope, address family, and ASN because those fields anchor the route itself. Then read country and timezone. Only after that should city, postal code, and coordinates shape the story. If country and ASN stay stable while city moves, that usually means provider database differences rather than a dramatic route change.

Dual-stack checks deserve one extra step. If the page shows both current IPv4 and current IPv6 routes, an allowlist or vendor handoff may need both values even when you only inspected one of them as the primary target. The page is careful to show both paths because real production issues often hide in that mismatch.

Step-by-Step Guide

  1. Leave the IP field blank to inspect the current connection, or enter one public IPv4 or IPv6 address if you already know the target you want to audit.
  2. Choose Preferred family if you want auto-detection to favor IPv4 or IPv6 when both are available.
  3. Choose Consensus cross-check for richer troubleshooting evidence, or Fastest successful for a quick one-source answer.
  4. Keep Reverse DNS lookup on when a hostname clue would help a support or mail-path handoff. Turn it off only when you want the leanest possible run.
  5. Run the check and read the summary badges first, then scan Routing Snapshot for the exact address, ASN, operator, timezone, and alignment values.
  6. Use Source Consensus, Location Drift Map, Next Checks, and JSON only as far as the task needs, then export CSV, DOCX, chart files, or JSON if you need to share the evidence.

Interpreting Results

The first reading is about route identity, not place names. A green Global public scope badge tells you the inspected address belongs to a publicly routable range. The family badge tells you whether the browser exposed only IPv4, only IPv6, or both. The ASN and operator tell you which network is announcing or operating the route. Those facts usually stay useful even when location labels are fuzzy.

The consensus badge tells you how much confidence the page has in its own normalized story. Consensus strong means the two shipped enrichment sources largely agreed on the fields they both reported. Consensus mixed means at least one important field drifted. Single source means only one enrichment source came back. Detected path only means the page still found the outward-facing IP but could not build a provider-backed profile around it.

How to interpret common IP checker result patterns
Observed pattern What it usually means What to do next
Consensus strong and low coordinate spread The available sources mostly agree on the route's coarse location and operator context. Good for a fast VPN or region sanity check, but still not proof of a person's exact location.
Consensus mixed At least one field such as city, timezone, or operator differs across sources. Lean on country, timezone, and ASN first, then treat city and map markers as secondary clues.
Single source Only one enrichment reply succeeded, so there is no real cross-check. Use the returned IP and ASN, but be cautious about city, postal code, and coordinates.
Detected path only The page found the outward-facing IP, but enrichment providers did not answer. Retry later or from another browser session if you need geolocation or operator detail.
Wide coordinate spread Different providers placed the same route in noticeably different spots. Use the map as a disagreement display, not as a precise locator.
PTR answer present A reverse-DNS hostname was published for the inspected address. Use it as a hostname clue, not as guaranteed ownership proof.

If the map shows several markers, that is not a rendering bug. It means the enrichment sources returned different coordinate pairs for the same route. When that happens, the most reliable story usually comes from combining country, timezone, ASN, and the provider ledger rather than asking the map to settle the argument alone.

Worked Examples

Checking a VPN exit before opening a ticket

Run the page once before you connect to the VPN and once after. Compare the checked IP, ASN, timezone, and operator first. If those all move in the direction you expected, the VPN exit is probably behaving as intended even if the city label is not perfect.

Preparing a firewall allowlist request

A support team usually needs more than a screenshot of a map. Export the Routing Snapshot table or the JSON payload so the exact IP, ASN, operator, and timezone move into the handoff without retyping. If the current session exposes both IPv4 and IPv6, include both route values in the request.

Explaining why the city looks wrong

Suppose the country and ASN look familiar, but one provider says one city and another says a nearby metro area. That is a normal case for Consensus mixed. The safer reading is that the route exits through the expected operator and region, while the providers disagree on the last layer of geolocation detail.

Inspecting a vendor-supplied public IP

When a vendor sends a public address for an ACL change, switch to manual mode, paste the address, and run the check. If the page rejects it as private, documentation, or another non-global class, you have caught a bad handoff before it reaches the firewall team.

FAQ:

Does this show my exact physical location?

No. It shows network-level geolocation and route metadata for the public address, and those estimates can be broad or inconsistent across providers.

Can I inspect a private or example address?

No. Manual mode only accepts globally routable public IPv4 or IPv6 addresses. Private, loopback, link-local, documentation, and similar ranges are rejected before enrichment.

Why can the checked IP differ from one of the current path rows?

The page can detect both a current IPv4 route and a current IPv6 route, but it only inspects one target at a time. The preferred-family setting decides which path becomes the main target when the input is blank.

Why is the PTR field blank?

Many public IP addresses simply do not publish a PTR record. A blank PTR result does not mean the address is invalid.

Why does the map show more than one marker?

In consensus mode, each successful enrichment source can contribute its own coordinates. Multiple markers mean the providers did not map the route to the same point.

Does the page keep a history of what I checked?

It does not store a site-side history in cookies or browser storage, but the active settings can appear in the URL and in exported files, so treat those artifacts as shareable records.

Glossary:

Public IP address
The outward-facing address that remote services see when traffic leaves the local network.
ASN
An Autonomous System Number used to identify a network operator and its routing policy.
PTR record
A reverse-DNS record that maps an IP address back to a hostname when the operator has published one.
Dual-stack
A connection state where both public IPv4 and public IPv6 routes are available.
Coordinate spread
The largest distance between the chosen provider coordinates and the other reported coordinates for the same route.