Paste IP addresses, one per line, and get city, region, country, postcode, coordinates, timezone and the network behind them. It works - 21 of our 25 runs came back clean. It is also an estimate, and this page shows you exactly how much it moved between runs.
Twenty-one of our twenty-five runs came back ok, each with a city, a region, a country and country code, a postcode, coordinates, a timezone and the network operator. As a sanity check we ran a well-known public resolver address: it came back in Ashburn, Virginia, on Google LLC, with the organisation reading Google Public DNS and the autonomous system AS15169. That is the correct answer.
This is the part most IP lookup pages leave out. One address in our set was queried seven times and came back as two different cities, with two different postcodes and coordinates about 200 km apart. Another was queried nine times: the city held steady, the postcode and coordinates did not. The country, the operator and the network number were stable throughout. Trust this data at country and network level; treat the city as a hint.
From the sixteen-column generation onward there is a source column naming the upstream providers that were consulted - two of them on our six-column-richer rows, three on the richest ones. That is unusually candid for a lookup service, and it is the column that explains the movement above: the answer changed when the provider mix changed, not at random.
Our folder holds fourteen, sixteen and twenty-seven column forms, and the whole progression happened inside about half an hour on 15 July 2026. Sixteen adds hostname and source. Twenty-seven adds continent, district, UTC offset, currency, calling code, the AS name, the operator's domain, and four flags: mobile, proxy, hosting and is_eu. Write your importer to tolerate all three.
We have the clean experiment for this. One run submitted an address with a port appended and came back invalid query; six minutes later the same address without the port returned a full row. Our other rejected inputs were a single stray letter and a URL. Strip ports, strip schemes, one address per line - and read status, because a rejected input still produces a row.
First: lat and lon arrive as JSON numbers in the fourteen-column form and as strings in the later two - a strict loader will break on one of them. Second: the flags in the richest form are the strings "no", not booleans. Coerce both at import rather than trusting the first file you see.
The fourteen columns below are the base form, present in every generation we hold. The counts come from our own 25 runs. The later generations add the fields described in the note underneath.
query - including, unhelpfully, on the rejected rows, where it echoes whatever you sent rather than an address. Read status before trusting it.lat. Together they place the address to within a city, not a building - see the note below.America/New_York. Stable across our repeats, and generally the safest way to derive local time from an address.isp; on a well-known public resolver it was the more specific of the two, naming the service rather than the company.asname column. This is the most stable identifier in the export.ok on 21 rows and invalid query on 4 - a port-suffixed address, a stray letter and a URL submitted twice. Reconcile on this column, because a rejected input still produces a row.14 to 27 columns per row · CSV, JSON or Excel
Two things to design around. First, the schema. Our folder holds three generations and the whole progression happened inside about half an hour on 15 July 2026. The sixteen-column form adds hostname - sparse, populated on a minority of rows - and source, which names the upstream providers consulted. The twenty-seven-column form adds continent, district (empty on both rows we hold), utc_offset, currency, calling_code, asname, domain, and the flags mobile, proxy, hosting and is_eu - all four arriving as the string "no" rather than as booleans. Second, precision. One address in our set was queried seven times and returned two different cities, two postcodes and coordinates roughly 200 km apart; another was queried nine times and kept its city while its postcode and coordinates shifted. Country, region, operator and autonomous system held steady throughout. Build on those; treat city and coordinates as an estimate that can move when the provider mix does.
Country code and autonomous system were the two most stable fields across all our repeats. Enrich a log export with those and you can answer which markets and which networks your traffic comes from - without pretending to know which street corner it came from.
The richest generation carries hosting, proxy and mobile flags alongside the operator name. That is the difference between a visitor on a consumer broadband line and traffic arriving from a server, which is often the distinction you actually need.
timezone arrived on every clean row as a proper IANA name, and the richest generation adds currency, calling code and UTC offset. For choosing a default rather than asserting a fact, that is exactly the right resolution.
One address per line, one row per address, and a status flag that tells you which inputs were rejected rather than silently dropping them. Our own rejected rows were a port-suffixed address, a stray letter and a URL - all things a real input list contains.
One time, on signup. No card, and nothing to cancel afterwards.
Billed on rows actually returned. One address is one row here, so the arithmetic is unusually easy: a list of a thousand addresses is a thousand rows.
Credits do not expire on a monthly cycle. Enrich a log export once a quarter and nothing in between if that is the shape of the work.
LIVESCRAPER10 at checkout.The natural next step: this service hands you coordinates, and that one turns coordinates into an address - bearing in mind the precision caveat on this page.
The other half of the same question. The richest generation here returns the operator's domain, which is where the two datasets meet.
Traffic and audience figures for a site, when the question moves from where a visitor connected to who visits a domain.
An address into coordinates - the same journey in the opposite direction, and a way to check one estimate against another.
This page cannot use the answer our product pages use. On every other service here we can say that nothing in the export describes a person. That is not true of an IP address, and pretending otherwise would be the wrong kind of reassurance.
Start with the honest position. An IP address is widely treated as personal data in the European Union - the question turns on whether it can be linked to an individual, and for an address handed out to a home connection it often can be, at least by the operator. That does not make a lookup unlawful; it does mean the lookup falls under data-protection law, and that you need a lawful basis for it, a retention period, and a reason you could explain if asked. Ordinary uses like fraud checks, abuse handling, security logging and audience analytics are well-trodden ground. Building a profile of an individual person's movements is not, and this service is not the tool for it.
Second, the resolution. What comes back is a network's estimated location, not a person's address, and our own runs show why that matters: one address in our set returned two different cities across seven queries, with coordinates roughly 200 km apart, while the country, the region, the operator and the network number stayed put. If a decision would be unfair when the city is wrong, do not make it on the city. Country and network are what this data supports, and even they describe a connection rather than a household. The coordinates are a centroid, and treating them as a location is a mistake this page would rather you not make on our account.
Our own terms are the same as on every other service here. Publicly available data only, no third-party trackers on the data layer, and exports auto-delete after 30 days - which for this service is a feature rather than a footnote, since a shorter retention period is easier to justify. Your first 500 rows are free and need no credit card.
invalid query, and six minutes later the same address without the port returned a full row.source column naming the providers consulted, and the rows that disagree with each other are the rows with different values in it. That is an argument for storing source alongside the answer, not for distrusting the service.country_code, country, region, timezone and the autonomous system were stable on every repeated address we hold. isp is stable as an entity but not as a string - the same operator appeared under three spellings - so normalise before grouping.hostname and source; twenty-seven adds continent, district, UTC offset, currency, calling code, AS name, operator domain and four flags.mobile, proxy, hosting and is_eu arrive as the string "no" on the rows we hold. And lat and lon are JSON numbers in the fourteen-column form but strings in the later two, so coerce both at import rather than trusting the first file you see.invalid query in the status column and your input echoed back in query and ip. Four of our twenty-five runs went that way. Read the status column before you treat the address field as an address.One address per line, one row back, with the operator and the network on every clean row - and an honest account of how far the city estimate can move. Your first 500 rows are free, then $0.002 each.
This service takes IP addresses rather than URLs, which already sets it apart from most of the catalogue on this site. You paste a list, one address per line, and each address comes back as a row: the city, region, country and country code it is estimated to sit in, a postcode, latitude and longitude, an IANA timezone, the internet service provider, the organisation the address is registered to, and the autonomous system number that carries it. Our folder holds twenty-five runs across six distinct addresses, of which twenty-one returned a clean row. As a correctness check we looked up a well-known public resolver address and it came back in Ashburn, Virginia, on Google's network, with the organisation naming the public DNS service and the autonomous system reading AS15169 - which is the right answer.
The part worth reading before you build on it is precision, and we can be specific rather than hand-waving because we ran the same addresses repeatedly. One address was queried seven times and came back as two different cities, with two different postcodes and coordinates roughly two hundred kilometres apart. Another was queried nine times: its city stayed put while its postcode and coordinates moved. Through all of that, the country, the region, the network operator and the autonomous system number never changed. The lesson is not that the data is unreliable - it is that different fields have different reliability, and the export does not tell you which is which unless someone measures it. Country and network are solid. City is a useful hint. Coordinates are a centroid, and treating them as a location will eventually embarrass a report.
From the sixteen-column generation onward there is a source column that names the upstream providers consulted for that row, and it explains the movement above: the rows that disagree are the rows with a different provider mix, not random noise. Store that column alongside the answer and a future discrepancy becomes explainable instead of mysterious. The schema itself grew twice inside about half an hour on 15 July 2026 - fourteen columns, then sixteen with hostname and source, then twenty-seven adding continent, district, UTC offset, currency, calling code, the AS name, the operator's domain and four flags for mobile, proxy, hosting and EU membership. Write the importer to tolerate all three, and coerce as you go: latitude and longitude are JSON numbers in the earliest form and strings in the later two, and the flags are the string "no" rather than booleans.
One last thing, and it is the reason this page does not end the way our product pages do. Every other service in this catalogue can honestly say that nothing in its export describes a person. This one cannot. An IP address is widely treated as personal data in the European Union, because it can often be linked back to a subscriber. That does not make a lookup unlawful - security, fraud prevention, abuse handling and audience analytics are ordinary and well-established uses - but it does put the work inside data-protection law, which means a lawful basis, a retention period and a reason you could defend. Building a picture of one individual's movements is not what this is for. Our exports auto-delete after 30 days, publicly available data only, no third-party trackers on the data layer, and your first 500 rows are free with no credit card.