IP Extractor
every address, with the line it came from

What the IP extractor result shows

Every row is one address. The extractor reports the address exactly as it was written and again in its canonical form, the line number it was first seen on together with that line in full, the line it was last seen on, how many times it occurs, whether it is IPv4 or IPv6, any port or prefix length attached to it, and the IANA Special-Purpose block it falls inside with that block's RFC and the registry's own Globally Reachable value.

The line number is the column that changes how the list is used. When you extract IPs from a log file the addresses are only the start of the question; the useful part is the request, the status code or the rule that sat on the same line. Most extractors hand back a bare list and leave you to search the original file again. The most capable of them is asked this in its own FAQ — can I preserve the original context, the line number and surrounding text, of each extracted address? — and answers only that its output is a clean deduplicated list. Checked again on 29 September 2026. Here the line comes with the address, so a suspicious entry is one glance from its context.

Sorting is deliberately limited to three orders — first seen, most frequent and numeric. If the list itself is the job, and you want it collapsed into ranges, deduplicated across several pasted files or ordered properly across mixed IPv4 and IPv6, that is a different tool: the IP sorter handles ordering and deduplication of an address list. And if the reason you are extracting addresses in the first place is to stop something, the full picture of where a block can be applied is in the guide to blocking an IP address at every layer.

Every format this IP address extractor accepts

An IP address extractor is only as good as the spellings it recognises. Real text is messy: an address may be bracketed with a port, carry a zone id, sit inside a CIDR prefix, be written with padded hextets, or be an IPv4 address hiding inside an IPv6 one. All of the following are read, and each is normalised before counting.

What is refused, and counted

Refusing something quietly is the failure mode that matters, so every refused candidate is tallied with its reason and up to three examples. A run of text only becomes a candidate if it is address-shaped in the first place: three or more numeric groups joined by dots, or two or more colons with hex digits. A word like deadbeef or a lone key:value is never a candidate, so it is never a rejection either.

A prefix in the list is read as a block, not expanded into the addresses inside it. Going the other way — turning a first and last address into the smallest set of prefixes that covers them — is what the IP range to CIDR converter is for, and it is usually the next step after a bulk IP extractor run on a firewall log.

IPv6 gets the same treatment as IPv4 rather than being an afterthought. If your reason for being here is to extract IPv6 addresses specifically, every form in the first table above is read, normalised per RFC 5952 and classified against the IANA IPv6 registry, including the link-local and unique-local ranges that dominate internal logs.

The leading-zero trap: 010.1.1.1 is not 10.1.1.1

Write 010.1.1.1 in a firewall rule and two pieces of software will disagree about which host you meant. Strict parsers refuse it outright. The C library that sits under ping, getent and a great deal of command-line tooling reads a leading zero as octal, so 010 is 8 and the address becomes 8.1.1.1. That is not a bug in either one, and it is not our interpretation. RFC 6943 section 3.1.1 records it:

In specifying the inet_addr() API, the Portable Operating System Interface (POSIX) standard [IEEE-1003.1] defines "IPv4 dotted decimal notation" as allowing not only strings of the form "10.0.1.2" but also allowing octal and hexadecimal, and addresses with less than four parts. For example, "10.0.258", "0xA000102", and "012.0x102" all represent the same IPv4 address in standard "IPv4 dotted decimal" notation.

— RFC 6943, Issues in Identifier Comparison for Security Purposes, section 3.1.1 (Thaler, Ed., May 2013)

Measured, not assumed

Because this is the kind of claim that gets repeated without checking, it was measured. On 29 September 2026, 1,049 inputs were run through eight implementations on one machine — Ubuntu 24.04.4 LTS with glibc 2.39-0ubuntu8.7, PHP 8.4.21, Python 3.11.15 and Node v22.22.2 — giving 8,392 observations. The inputs were the first octet written as every value from 0 to 255 in four paddings (7, 07, 007, 0007) plus a curated set of short, hexadecimal and integer forms, including the three the RFC names.

So when this extractor meets 010.1.1.1, it does not pick a side. It reports 10.1.1.1 as the plain reading, flags the row, and shows 8.1.1.1 as the octal reading. Where the padding cannot be octal at all — 08 or 09 — the row is flagged octal invalid, which is the honest answer: the C library refuses that string entirely, so no rule written with it will ever match anything.

The same section of the RFC is why hexadecimal and packed-integer forms are reported but not decoded here. 0xA000102 and 012.0x102 both mean 10.0.1.2 to inet_aton — the measurement above confirms it on this machine — but silently converting them would put an address in your list that never appeared in your text. They are counted as rejections with the reason stated instead.

What the IANA block tells you about an address

A list of addresses with no idea which ones can reach you is a list you cannot act on. Every address found here is matched, longest prefix first, against the IANA IPv4 Special-Purpose Address Space registry and its IPv6 counterpart. Both were read on 25 September 2026 and each carries its own Last Updated 2025-10-09. The registry's Globally Reachable column is copied as it stands, not derived from anything on this page, and it means:

A boolean value indicating whether an IP datagram whose destination address is drawn from the allocated special-purpose address block is forwardable beyond a specified administrative domain.

— the definition the registry uses, set out as the Global attribute in RFC 6890 section 2.2.1 (April 2013).

These are the blocks that turn up most often in a real log, and what each one means when it appears:

Anything that matches no special-purpose block is ordinary public unicast, and those are the rows that matter when you are deciding what to keep out. The next question is usually whose network it is: a datacentre range behaves nothing like a residential one, and the trade-offs of drawing that line are covered in blocking datacentre and hosting IPs without breaking your own integrations.

Where the registry has no answer, neither does this tool

Two results say N/A rather than Yes or No, and the reason is the same in both cases: there is no value to copy.

• Multicast (224.0.0.0/4, ff00::/8) is not in the special-purpose registry at all — it has its own, RFC 5771 — so there is no Globally Reachable column for it. It is also never a source address you would block, so it stays out of the blocklist output.
• Unassigned space. Most of IPv6 has never been allocated. An address there matches no row, so the block, the RFC and the reachability are all left empty rather than filled with a citation that does not exist. Some tools call this space globally reachable by elimination; nothing has been delegated there, so this tool does not.

What looks like an IP address but is not

Four numbers under 256 joined by dots is a version number as often as it is an address. Anyone who tries to find IP addresses in text hits this immediately, and the usual response is a confident sentence claiming false positives are rare. Here is a number instead.

The rule that removes most of them

A candidate glued to the end of a word is not a candidate. 0ubuntu0.24.04.4 contains 0.24.04.4, which is four groups all under 256 — but it is preceded by a letter, so it is skipped. The single exception is a v prefix standing on its own: v1.2.3.4 really might be an address written carelessly, so it is extracted and flagged version context rather than dropped. That is the whole philosophy of this extractor — a doubtful row you can see beats a real address you never knew was there.

Measured over real text

Five corpora, all real files on one machine, chosen because they are known to contain no IP addresses at all. Every acceptance is therefore a false positive by definition. The per-corpus unique counts overlap — the package log repeats the same seven version numbers as the version list — so the total counts distinct strings, not the sum of the column.

Those same corpora produced 15,815 refused candidates, almost all of them either clock times (9,501) or numbers with fewer than four groups (6,160) — which is the other half of the picture: the reject counter tells you what the extractor decided against, so you can judge whether it decided correctly.

Extracting IP addresses without a tool: grep, a regex, and what each one misses

You do not need this page to get addresses out of a file, and it is worth knowing exactly what the command-line answer gives you and where it stops. Every command below was run against the same six-line test log before it was published here, and the output shown is the output it produced.

The regex everybody uses

It works, and it is the right reach for a quick look. It also accepts 999.999.999.999, because [0-9]{1,3} says nothing about the range of an octet.

The regex that gets the octets right — and hides something

999.999.999.999 is gone, which is the improvement people reach for. Look at line 5. The file says 010.1.1.1; the regex reports 10.1.1.1, because it simply starts matching after the zero. The leading zero has not been handled, it has been made invisible — and the address the C library would resolve is 8.1.1.1, a third value that appears nowhere in either output.

Counts are easy, IPv6 is not

Four matches, one address. Nothing shorter than a real parser separates an IPv6 address from an Apache time stamp, because they are the same shape.

Ten lines of Python gets much closer

No time stamps, no 999.999.999.999, and a line number. It still misses 10.0.3.14, because the candidate it cut out was 10.0.3.14:8443 and that is not an address to ipaddress; it drops 010.1.1.1 without a word, because the strict parser refuses it; and it will not keep a CIDR prefix, a zone id or a port.

From an extracted list to a working blocklist

The Blocklist ready output exists because a raw extraction is not a blocklist. It keeps only the addresses the IANA registries mark globally reachable, drops ports and zone ids, keeps any CIDR prefix intact and sorts numerically. Loopback, RFC 1918 space, carrier-grade NAT and documentation ranges are left out on purpose: a firewall rule against 127.0.0.1 or 192.0.2.5 costs you a line of config and blocks nothing.

Three things are worth doing before any of it reaches a live rule:

1. Check what the addresses are. A crawler you actually want has to survive the list. Paste the extracted addresses into the bulk bot IP checker first — forward and reverse DNS is the only way to tell a real Googlebot from something claiming to be one.
2. Collapse them into ranges. Two hundred individual lines from one network is a maintenance problem; the method for turning a first and last address into the fewest possible prefixes is set out in turning start and end addresses into CIDR blocks.
3. Apply it where it costs least. Blocking at the edge keeps the traffic off the origin entirely; the rule types, and when a custom rule beats a plain IP rule, are compared in blocking an IP address in Cloudflare.

For reference, the same list in three common formats:

The CSV output is the one to keep if the list is going into a ticket or a review: it carries the line number, the line text, the occurrence count and the IANA classification, which is the evidence for the rule rather than just the rule.

What this tool does not do

Being clear about the edges is part of being useful. This tool will not:

• Look anything up. No geolocation, no ASN, no WHOIS, no reputation score, no reverse DNS. It makes no network request at all, which is precisely why a log you are not allowed to upload anywhere is safe to paste here.
• Expand a CIDR block. 10.0.0.0/8 is reported as one block, not 16,777,216 addresses.
• Merge or compare ranges. Overlap and containment are separate questions with separate tools.
• Sort or deduplicate across files. Three orders are offered for reading the result; anything more belongs to a dedicated sorter.
• Decode hexadecimal or packed-integer notation. These are detected and counted, never silently converted into an address that was not written in your text.
• Read a PDF, a Word file or a compressed archive. Plain text only: paste it, or drop a text-based file.
• Judge intent. An address appearing four hundred times may be an attacker or a monitoring probe. The extractor gives you the count and the line; the conclusion is yours.

Frequently asked questions about extracting IP addresses