What Is My Internet Protocol (IP) Address?
Check IP address details online with current-route detection, ASN, timezone, source consensus, and PTR hostname clues for VPN checks or firewall allowlists.Public IP Snapshot
| Field | Value | Copy |
|---|---|---|
| {{ row.label }} | {{ row.value }} |
| 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.
|
|||||||
| Section | Signal | Detail | Copy |
|---|---|---|---|
| Recommended next check | {{ note.title }} | {{ note.body }} | |
| Current route note | {{ row.label }} | {{ row.value }} |
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.
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.
| 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 Snapshotwhen you need the copy-ready details table, CSV copy or download, and DOCX export. - Open
Source Consensuswhen you want to see how well the sources agree on address, country, city, timezone, operator, coordinates, and PTR. - Open
Location Drift Mapwhen you want to compare returned coordinates visually and open the chosen point in OpenStreetMap or Google Maps. - Open
Next Checkswhen you need a quick explanation of what to verify next for support, allowlisting, or VPN troubleshooting. - Open
JSONwhen 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
- 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.
- Choose
Preferred familyif you want auto-detection to favor IPv4 or IPv6 when both are available. - Choose
Consensus cross-checkfor richer troubleshooting evidence, orFastest successfulfor a quick one-source answer. - Keep
Reverse DNS lookupon when a hostname clue would help a support or mail-path handoff. Turn it off only when you want the leanest possible run. - Run the check and read the summary badges first, then scan
Routing Snapshotfor the exact address, ASN, operator, timezone, and alignment values. - Use
Source Consensus,Location Drift Map,Next Checks, andJSONonly 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.
| 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.
References:
- ipify API, ipify.
- IP Data Types, IPinfo.
- API Reference, ipapi.
- Terms of Service, ipapi.
- JSON API for DNS over HTTPS (DoH), Google Public DNS.
- RFC 1035: Domain Names - Implementation and Specification, IETF.
- Autonomous System Numbers, American Registry for Internet Numbers.
- RFC 1918: Address Allocation for Private Internets, IETF.
- RFC 4193: Unique Local IPv6 Unicast Addresses, IETF.
- IPv4 Special-Purpose Address Space, IANA.
- IPv6 Special-Purpose Address Space, IANA.