Bulk IP Lookup Free Tool
About Bulk IP Lookup
What This Tool Actually Does
Bulk IP Lookup is a browser-side form on this site that takes a list of IPv4 addresses, one per line, and turns each one into a table row with eight columns of geographic and network information. You paste addresses into the textarea above, press Submit, and watch the rows appear one by one without the page reloading. The tool caps every run at a fixed number of addresses, spaces its requests a tenth of a second apart, and asks a remote lookup service for each valid IPv4 address. What comes back is city, region, country, a two-letter country code, the ISP name, and latitude and longitude coordinates. The tool returns the ISP name for the IP address. It does not do WHOIS, it does not resolve hostnames, and it does not return ASN numbers, no matter what older descriptions of this page claimed.
The tool is built on the "A to Z SEO Tools" script by ProThemes.Biz, and the actual geo data arrives from a ProThemes.Biz remote endpoint. Your browser sends one request per line to this server, and this server forwards the query to that vendor service, scrapes seven fields from the reply, and hands a row back to your screen. Because the requests are spaced a tenth of a second apart, a full run of the maximum line count takes about two seconds to finish. Rows append to the table as they arrive, which means you can read the first results while the later ones are still coming in. If the remote service is down, every row will come back with "Not available" in the data columns, because this tool has no local database of its own to fall back on.
The output table has eight columns. The IP address appears first, colour-coded, and then come City, Region, Country with a small flag image, the two-letter Country Code, ISP, Latitude, and Longitude. Any field that the remote service could not fill shows the text "Not available". When you are done, an Export button downloads whatever has been collected as a file named geo-ip.csv, with the same eight columns in comma-separated format. A "Try New IP" button clears the table and reloads the form for another run.
The live test run for this rewrite used three inputs. The first was a public Google DNS server address, which returned Ashburn, Virginia, United States of America, the code US, the ISP Google LLC, and a coordinate pair in the northern Virginia area. The second was the IPv6 equivalent of that Google DNS address, which produced a row with the address shown and every other cell empty, plus a flag labelled "unknown". The third was the text "abc", which produced a row reading "No valid IP" with dashes in the data columns. Those three results define the behaviour of the tool in practice.
How to Use This Tool
- Open the tool page. Find the input box above this article, which is a textarea labelled "Enter up to 20 IPs (Each IP must be on separate line)".
- Prepare your address list. Put each IPv4 address on its own line, with no extra text, no hostnames, and no commas. Twenty lines is the maximum, and anything past line 20 is silently ignored.
- Submit the list. Click the Submit button. If the box is empty, a popup will ask you for input. Otherwise the tool begins sending one request per line, a tenth of a second apart, and rows appear in the table as results arrive.
- Read the eight columns. Check IP Address, City, Region, Country, Country Code, ISP, Latitude, and Longitude for each row. Missing fields show "Not available", and a bad line shows "No valid IP".
- Export the results. Click the Export button to download a file called geo-ip.csv containing the same eight columns, comma separated, for every row collected so far.
- Run another batch. Click "Try New IP" to clear the table and start over with a fresh list of up to 20 addresses.
The tool runs entirely in your browser with JavaScript, so there is no page reload between your click and the first row. The text area placeholder shows "eg. 171.24.46.35", which is a sample IPv4 address in the familiar dotted-quad format. If you paste a block of text with blank lines, those blank lines will produce "No valid IP" rows, so you should clean your list before submitting. The spacing between requests is built into the tool, and it exists to keep this site's server from being hit by a burst of simultaneous requests.
Reading the Eight Output Columns
The table that the tool builds has a fixed structure, and understanding each column helps you interpret what the remote lookup service actually returned. The IP Address column is first and is colour-coded, which simply makes each row easier to scan when you have a full table of results. Then come the two location columns, City and Region, followed by Country with a small flag image beside it. The Country Code column holds the two-letter ISO code such as US or GB. ISP names the organisation that the remote database associates with the address block. Latitude and Longitude finish the row as decimal numbers.
City and Region are the most interesting columns, because they are where the limitations of registration-based geolocation show up most clearly. When the remote service says an address is in Ashburn, Virginia, it usually means that the organisation which registered the IP block has its network equipment or its registered address in that city. It does not mean the person using that address is physically in Ashburn. The same logic applies to Region, which in the Google DNS test returned Virginia. Google LLC registered that block, and Google's public DNS infrastructure is associated with Ashburn, a city known for its data centres. A residential user on that block would appear to be in Ashburn too, even if they live in another state.
The Country and Country Code columns come from the same registration data. The Country cell includes a small flag image, and the Code cell holds the two-letter abbreviation. In the live test, the Google DNS address returned "United States of America" and "US". When the remote service cannot identify a country, or when this site has no flag image for the country name that came back, the flag can show the text "unknown". That is a display quirk of the tool's interface.
ISP is the column that names the network operator. For the Google DNS address, the ISP column read "Google LLC", which is the organisation that owns the address block. For a typical home broadband address, this column would name the internet service provider such as Comcast, BT, or Deutsche Telekom. ISP here means the owner of the block, and in most cases that is the company that provides connectivity to the specific device at the moment of the lookup. With corporate blocks and mobile carriers the distinction can matter.
Latitude and Longitude are decimal coordinates, and in the Google DNS test they came back as a pair near the northern Virginia area. Those coordinates place the address in the Ashburn region. The precision of these coordinates depends entirely on the remote database. For addresses owned by large ISPs, the coordinates often point at the ISP's registered city or at a central location for the region. The tool does no GPS work of its own. It simply passes through whatever coordinates the remote service supplies.
| Column | What it holds | Example from Google DNS |
|---|---|---|
| IP Address | The queried address, colour-coded | 8.8.8.8 |
| City | Registration city of the block | Ashburn |
| Region | State or province | Virginia |
| Country | Full country name with flag | United States of America |
| Country Code | Two-letter ISO code | US |
| ISP | Owner of the address block | Google LLC |
| Latitude | Decimal latitude | 39.03 |
| Longitude | Decimal longitude | -77.5 |
All eight columns come from one external registration database, and none of them are measured or observed from the live behaviour of the address.
Correcting the Old Description of This Tool
The previous version of this page described a tool that does not exist. This section names those claims directly so that returning visitors can adjust their expectations. The old copy said the tool handled "dozens or hundreds of IPs" and that you could "paste as a block of text". The real tool accepts a fixed number of addresses per run, one per line, and silently ignores anything after the limit. There is no way to paste a very large list and get a matching number of rows. You would need many separate runs to cover that volume.
The old copy also claimed the output included "the hosting provider, the ASN that owns the IP block, and often the hostname resolved through reverse DNS". None of those columns exist in the output. The eight columns are IP Address, City, Region, Country, Country Code, ISP, Latitude, and Longitude. There is no ASN column, no hostname column, and no reverse DNS lookup anywhere in the code. The ISP column names the block owner, which relates to the ASN concept. An ASN is a number assigned to a network, and this tool never displays one.
The old page said the tool "works for both IPv4 and IPv6". The live test with an IPv6 address produced a row with the address shown and every other cell empty, plus a flag reading "unknown". The code recognises IPv6 syntax as valid but never calls the lookup service for those addresses. IPv6 support is unavailable in practice. If you need location data for IPv6 addresses, this tool will not give it to you.
The old copy described a WHOIS and ASN section "under the hood" of the tool. Nothing WHOIS-based is queried. The tool sends each IPv4 address to a ProThemes.Biz remote lookup service and scrapes seven fields from the reply. There is no WHOIS client, no RDAP query, and no direct connection to any regional internet registry. The phrase "under the hood" described machinery that the code does not contain.
| Old claim | Real behaviour |
|---|---|
| Dozens or hundreds of IPs per run | Fixed cap per run, lines past it ignored |
| Paste as a block of text | One address per line, blank lines give errors |
| ASN in the output | No ASN column exists |
| Hostname from reverse DNS | No reverse DNS lookup happens |
| Works for IPv4 and IPv6 | IPv6 rows come back empty |
| WHOIS under the hood | Data comes from a ProThemes.Biz geo endpoint |
The tool is smaller and simpler than the old page advertised, and the practical consequence is that you should plan your lookups in batches of IPv4 addresses.
The Address Cap and How to Batch
The single most important limit on this tool is the line cap. The code reads the textarea, splits it on newlines, and processes only the first set of lines. Anything after that limit is silently ignored, with no warning and no error message. If you paste more addresses than the cap allows, you will get rows only for the first portion and the rest will simply vanish. The tool does not tell you that it dropped them, so it is your responsibility to count your lines before submitting.
The cap exists because each address triggers a separate request to the remote lookup service, and the tool spaces those requests a tenth of a second apart. A full run means roughly two seconds of sustained querying. There is no tool-specific request cap and no CAPTCHA on this page, but a shared site-wide throttle applies to every page of this site. More than fifteen requests within a single second from one visitor address blocks that address for the rest of the day. The tool's own spacing of about ten requests per second stays under that threshold, but running two tabs of this tool at the same time can trip it, because the two tabs together send about double the safe rate.
Batching is straightforward. If you have a large list of addresses to look up, you run the tool multiple times with the maximum number of lines each. After the first run, click "Try New IP", paste the next set of lines, and submit again. The Export button downloads only what has been collected in the current run, so if you want a single CSV file for all your addresses, you would need to export each run separately and combine the files in a spreadsheet program. There is no server-side history and no way to resume a previous run.
The one-run-at-a-time rule comes from the same throttle logic. The tool does not queue runs or let you start a second batch while the first is still filling in rows. If you submit a second list before the first has finished, you risk sending more than fifteen requests in one second from your address, which would return a 503 error for the rest of the day. The safe pattern is to wait for the table to finish filling, export if you want the CSV, then clear and start the next batch.
| Batch size | Runs needed | Approximate time |
|---|---|---|
| Up to 20 addresses | One run | About 2 seconds |
| 21 to 40 addresses | Two runs | About 4 seconds |
| 41 to 60 addresses | Three runs | About 6 seconds |
| 100 addresses | Five runs | About 10 seconds |
The cap is a hard code limit, and the throttle means you should run batches sequentially rather than in parallel tabs.
What Registration-Based Geolocation Can and Cannot Tell You
Geolocation by IP address is a statistical art, and this tool practises it through a remote database that maps address blocks to registration locations. When the Internet Assigned Numbers Authority and the regional registries hand out address space, they record which organisation received each block and where that organisation is based. The remote lookup service that powers this tool draws on that registration data, which is why the Google DNS test landed on Google LLC in Ashburn, Virginia. The database records the block's registration location.
A block's registration city can differ from a user's actual location. A large ISP such as Comcast or AT&T may register an address block in one city and assign addresses from that block to customers across several states. A lookup on such an address will return the registration city, which could be hundreds of miles from the person who is actually online. Mobile carriers make this worse, because they often register blocks nationally and assign addresses dynamically as users roam between cell towers. The latitude and longitude columns in this tool's output inherit all of that imprecision.
Virtual private networks and proxies defeat registration-based geolocation entirely. When you connect through a VPN, your traffic exits through a server owned by the VPN provider, and the IP address that a lookup sees belongs to that server's block. The remote database will report the VPN provider's registration location, which is often a data centre city such as Amsterdam, Frankfurt, or Ashburn, regardless of where you actually are. The tool has no way to detect that an address belongs to a VPN or proxy, because it does not maintain a list of known VPN ranges and it does not perform any active probing. A row that says "Amsterdam" may be a person in Berlin using a Dutch VPN server.
Content delivery networks add another layer of distance between registration and reality. CDN providers such as Cloudflare, Akamai, and Amazon CloudFront operate servers in hundreds of cities, and they often use anycast addressing, where the same IP address is announced from multiple locations around the world. A lookup on a CDN address returns the registration location of the block, which may be the company's headquarters city or a regional office, not the edge server that actually served your request. The Google DNS result is a mild example of this, since Google operates that address from many data centres, but the database reports the Ashburn registration.
| What the tool can show | What the tool cannot show |
|---|---|
| Registration city of the block | Physical location of the user |
| Block owner name as ISP | Whether the address is a VPN |
| Country of registration | Whether the address is a proxy |
| Decimal coordinates of the block | Whether the address is a CDN node |
| Two-letter country code | Timezone of the user |
Registration-based geolocation gives you a plausible region, often the right country and sometimes the right city, based on a database guess.
What Is Missing From This Tool
The list of missing features is long, and knowing it will save you from expecting output that never arrives. There is no ASN column, which means you cannot learn the autonomous system number that owns the block. There is no hostname column, because the tool never performs reverse DNS lookups. There is no WHOIS section, so you cannot see the registered owner, the abuse contact email, or the registration and expiry dates of the block. There are no proxy, VPN, or hosting flags, so the tool cannot tell you whether an address belongs to a data centre or a home broadband connection. There is no timezone column, despite the fact that some geolocation databases include it.
The absence of ASN data matters, because ASN information is often what people actually want when they ask for a "bulk IP lookup". An ASN identifies the network that announces an IP block into the global routing table, and knowing the ASN tells you whether an address belongs to a university, a cloud provider, a telecom, or a small business. This tool provides the ISP name associated with the IP address. Google LLC is the ISP name for the Google DNS address, and the ASN for that address is AS15169, but the tool will never show you the number. If your workflow depends on ASN data, you need a different service.
Reverse DNS is another absent feature. A reverse DNS lookup maps an IP address to a hostname, such as mapping the Google DNS address to dns.google. The tool does not perform this lookup, and the output table has no column for it. The old page's claim that the tool returned "the hostname resolved through reverse DNS" was false. If you need to know what hostname an address points to, you would use a command-line tool such as dig or nslookup, or a dedicated reverse DNS web service.
WHOIS data is completely absent. The tool never queries any WHOIS server, never contacts a regional internet registry, and never shows you the registered owner of a block beyond the ISP name that the geo service returns. There is no abuse contact, no registration date, no network name, and no RDAP record. The remote lookup service returns seven fields, and the tool displays all of them. Nothing else is fetched or computed.
| Missing feature | What it would tell you |
|---|---|
| ASN number | Which network announces the block |
| Reverse DNS hostname | What name maps back to the address |
| WHOIS owner | Who registered the block |
| Abuse contact | Where to report network abuse |
| Proxy and VPN flags | Whether the address is a tunnel endpoint |
| Timezone | Which time zone the address is in |
This tool is a geolocation and ISP lookup, and it makes no attempt to be a full network intelligence platform.
The Three Live Tests and What They Prove
The live test run for this rewrite used three carefully chosen inputs, and the results define the tool's real behaviour better than any description could. The first input was the well-known Google public DNS server address. The tool returned a complete row with Ashburn, Virginia, United States of America, the code US, the ISP Google LLC, and a coordinate pair near the northern Virginia area. This row proves that the tool works correctly for a normal, well-known IPv4 address and that the remote database has good registration data for Google's block.
The second input was the IPv6 equivalent of that Google DNS address. The tool produced a row with the address shown and every other cell empty, plus a flag reading "unknown". This row proves that IPv6 is not supported in practice. The code recognises the address as syntactically valid, but it never calls the lookup service for IPv6 addresses, so no data ever comes back. If you run a list of IPv6 addresses through this tool, you will get a table full of empty cells.
The third input was the text "abc", which is not an IP address at all. The tool produced a row reading "No valid IP" with dashes in the data columns. This row proves that the tool validates its input and gives you a clear signal when a line is unusable. The same result appears for hostnames such as "example.com" or "google.com", because the tool expects raw IP addresses, not domain names. If you paste a hostname, you get "No valid IP", and the tool will not resolve that hostname to an address for you.
| Input | Result |
|---|---|
| Google DNS IPv4 | Full row, Ashburn, Google LLC, US |
| Google DNS IPv6 | Address shown, all other cells empty |
| abc | Row reads "No valid IP" with dashes |
The tool reliably handles IPv4 addresses, silently fails on IPv6, and clearly flags invalid input, and you should plan your address lists accordingly.
Geographic Precision and the Accuracy Question
The accuracy of this tool's output is entirely dependent on the remote database that the ProThemes.Biz service maintains. This tool has no local geolocation data, no cached results, and no independent measurement of where an address is located. Every row you see is a pass-through from that external service. If the service is down, every row comes back with "Not available" in the data columns, and there is nothing this site can do to fill the gap.
City-level accuracy varies widely by address type. For large corporate blocks and data centre addresses, the registration city is often accurate, because companies register their blocks at their headquarters or at a major network hub. The Google DNS result of Ashburn is plausible, since Google operates public DNS nodes there. For residential broadband addresses, accuracy depends on how the ISP registers its blocks. Some ISPs register blocks at the city or town level, which gives good results. Others register large regional blocks at a central office, which means every customer in a multi-state region appears to be in the same city.
Country-level accuracy is generally high for registration-based databases. Country codes are assigned at the registry level, and it is rare for a block registered in one country to be used predominantly in another. The exceptions are multinational organisations, satellite internet providers, and some CDNs that hold blocks in one country and serve customers elsewhere. If you need country-level information for a list of addresses, this tool will usually give you a reliable answer. If you need street-level accuracy, no IP geolocation database can provide it, because IP addresses do not encode physical locations.
The coordinate columns deserve a special caution. Latitude and longitude in registration databases often point to the centroid of a city or to the ISP's office address, not to the user's home. A coordinate pair near the Ashburn area for the Google DNS address places it in a data centre region, but it does not identify a specific building. For addresses registered to mobile carriers, the coordinates can be off by hundreds of miles, because the block is registered at the carrier's headquarters while the user is on a tower elsewhere. Treat the coordinates as a rough regional indicator, not as a pin on a map.
| Address type | Expected city accuracy | Expected country accuracy |
|---|---|---|
| Data centre block | Often accurate | Very high |
| Corporate block | Usually accurate | Very high |
| Residential broadband | Varies by ISP | High |
| Mobile carrier | Often poor | High |
| CDN anycast | Registration city only | High |
The tool gives you registration-based estimates, and the estimates are most reliable at the country level and least reliable at the coordinate level.
The CSV Export and How to Use the File
The Export button downloads whatever has been collected in the current run as a file named geo-ip.csv. The file uses the same eight columns as the on-screen table, in the same order, with comma separation. IP Address comes first, then City, Region, Country, Country Code, ISP, Latitude, and Longitude. Check whether the downloaded file starts with column titles before importing it, and add or remove a header line as your spreadsheet needs. If you open the file in a spreadsheet program such as Microsoft Excel or Google Sheets, you may need to add a header row yourself for readability.
The export captures only what the table currently holds. If you submitted a full batch and all rows have arrived, the CSV will have a matching number of lines. If you export while rows are still coming in, the file will contain only the rows that have arrived so far. The tool does not wait for completion before exporting, so it is wise to let the table finish filling before you click Export. There is no way to append a second run to the same file from within the tool. Each Export click downloads a fresh file containing only the current table contents.
The CSV format is plain text with commas as delimiters. As with any simple CSV, a comma inside a value can shift columns when you import, so check rows with commas in the ISP or city. In the live test, the country "United States of America" contains no comma, and the ISP "Google LLC" contains no comma, so the sample file is clean. For other addresses, a city such as "Washington, D.C." would split into two columns in a naive CSV import. You can handle this by opening the file in a text editor first, or by using spreadsheet import settings that treat commas as delimiters only between fields.
| File property | Value |
|---|---|
| File name | geo-ip.csv |
| Column count | Eight |
| Delimiter | Comma |
| Row count | Matches current table |
The CSV export is a simple dump of the on-screen table, with no header and no quoting, so you should verify the file opens correctly in your spreadsheet of choice.
Performance, Rate Limits, and the Shared Throttle
This tool processes a query in under two seconds. A full run takes about two seconds, because each request is spaced a tenth of a second apart. There is no CAPTCHA on this page and no tool-specific request cap, but a shared site-wide throttle applies to every page of this site. The throttle works on a simple rule. More than about fifteen requests within a single second from one visitor address blocks that address for the rest of the day with a 503 error. The tool's own spacing of about ten requests per second stays safely under that limit during normal use.
The danger comes from parallel use. If you open two tabs of this tool and submit a full list in each tab at the same moment, the combined request rate exceeds the safe threshold. The throttle would then block your address for the rest of the day, affecting every page on this site, not just this tool. The safe pattern is to run one batch, wait for it to finish, and then start the next. There is no benefit to parallel runs anyway, because the tool does not combine results across tabs.
The spacing between requests is a deliberate design choice. It keeps the request rate under the site-wide throttle while still completing a full run in about two seconds. The spacing also reduces the load on the remote ProThemes.Biz service, which processes each address as a separate query. The total time for a run depends on how quickly the remote service answers each request.
The throttle is not specific to this tool. It applies to every page on limitlessreferrals.info, and it is implemented as a simple counter of requests per second per visitor address. If you are also using other tools on this site, such as the Domain into IP Converter or the Class C IP Checker, those requests count toward the same per-second budget. The practical rule is to use this site gently, one tool at a time, and to wait a few seconds between different tool runs.
| Usage pattern | Request rate | Throttle result |
|---|---|---|
| One tab, one run | About 10 per second | Safe |
| Two tabs at once | About double the safe rate | Blocked for the day |
| One tab, manual browsing | Under 1 per second | Safe |
| Automated script | Variable | Blocked if over 15 per second |
The tool is designed to stay under the site-wide throttle, but you must avoid running it in multiple tabs or combining it with heavy use of other tools on this site.
Realistic Use Cases for Bulk IP Lookup
The tool earns its keep in a specific set of scenarios, and knowing those scenarios helps you decide when to reach for it. The most common use is checking a list of visitor IP addresses from your server logs to see which country and city they registered in. If you run a website and you export a list of the IP addresses that visited yesterday, this tool can turn those raw addresses into country names and ISP names in about two seconds per batch. That gives you a rough sense of your audience's geographic spread without needing a full analytics platform.
A second use case is cleaning a mailing list or a user database. If you have collected IP addresses during signups, you can look them up in bulk to see which country each user appeared to be in. This works well when you only need country-level confirmation, such as verifying that a user who claims to be in Germany has a German IP address. The tool will not tell you whether that user is behind a VPN, so a German IP is not proof of physical presence, but it is a useful signal for fraud review.
A third use case is checking whether a set of addresses belongs to hosting providers. The ISP column is the key here. If you look up a list of addresses that you suspect are bots or scrapers, and the ISP column shows names like Amazon, Google Cloud, or DigitalOcean, you have reasonable evidence that the traffic comes from data centres. The tool does not flag hosting providers for you, but you can recognise the ISP names yourself. This is a manual version of the hosting detection that commercial bot-blocking services perform automatically.
A fourth use case is preparing data for a spreadsheet or a report. The Export button gives you a CSV file that you can merge with other data in Excel or Google Sheets. If you are building a report on where your site visitors come from, you can run several batches of addresses, export each one, and combine the files into a single table. The lack of a header row means you will add your own column titles, but the eight columns are consistent across every export, so the merging is straightforward.
| Use case | What the tool tells you | What it misses |
|---|---|---|
| Visitor log analysis | Country and city of registration | Real-time location |
| User database review | Country code and ISP | VPN detection |
| Bot traffic check | Hosting provider names | ASN confirmation |
| Report building | CSV export of all columns | Timezone data |
This tool enriches a list of IPv4 addresses with registration-based location and ISP data for country-level and ISP-level analysis.
Related Tools
If you need to convert domain names into IP addresses before you can run a bulk lookup, the Domain into IP Converter will turn a list of hostnames into their IPv4 addresses, which you can then paste into this tool.
When you want to check whether multiple IP addresses share the same Class C network, which is a common way to spot link farms or coordinated bot traffic, the Class C Ip Checker groups your addresses by their first three octets.
If you only need to know the details of your own current connection, the What is my IP address? The tool shows your own current IP address.
Frequently Asked Questions
Why does my IPv6 address come back with empty cells?
The tool recognises IPv6 syntax as valid but never sends those addresses to the remote lookup service. The live test with an IPv6 address produced a row with the address shown and every other cell empty. In practice, IPv6 is not supported, so you should only run IPv4 addresses through this tool.
What happens if I paste more than 20 addresses?
The tool reads only the first twenty lines of your input and silently ignores the rest. There is no warning message and no error. You should count your lines before submitting and split larger lists into multiple runs of 20 addresses each.
Why does a hostname like example.com show "No valid IP"?
The tool expects raw IP addresses, not domain names. When you paste a hostname, the input validation fails and the row reads "No valid IP" with dashes. You would need to resolve the hostname to an IP address first, using a DNS tool or the Domain into IP Converter on this site.
What does the ISP column actually tell me?
The ISP column names the organisation that registered the address block, according to the remote geolocation database. For the Google DNS address, that is Google LLC. It does not necessarily name the company that provides connectivity to the specific device at the moment of the lookup, especially for corporate blocks and mobile carriers.
Why does the flag sometimes show "unknown"?
The flag image comes from this site's own collection of country flag images. When the remote service returns a country name that has no matching flag image on this site, the flag cell shows the text "unknown". The Country and Country Code columns may still contain valid data in that case.
Can this tool tell me if an address is a VPN or a proxy?
No. The tool returns only the eight columns of registration-based data, and it does not maintain any list of known VPN or proxy ranges. A VPN address will simply show the registration location of the VPN provider's server, which is often a data centre city such as Amsterdam or Ashburn.