Skip to main content

How to Extract IP Addresses From Logs and Messy Text

A practical guide to pulling every valid IPv4 address out of access logs, configs, and pasted text, then deduping the list so you see the unique IPs hitting your server.

Published By Li Lei
#ipv4 #logs #networking #security #devops

How to Extract IP Addresses From Logs and Messy Text

A server log is a wall of text. Timestamps, request paths, status codes, user agents, ports, and somewhere in every line, an IP address. When something goes wrong, the IPs are usually what you actually care about: who hit the login endpoint 4,000 times last night, which client is hammering a rate-limited route, which addresses keep showing up in the 403 rows. The problem is that the IPs are buried, repeated thousands of times, and glued to other text. You need a clean, unique list, and you need it in about ten seconds.

That is exactly the job the IPv4 Address Extractor does. You paste the log, it pulls every valid address out, drops the surrounding noise, deduplicates the result, and hands you back a short list you can read, sort, copy, and export.

What counts as a valid IPv4 address

It helps to be precise about what the extractor is looking for, because that precision is what keeps junk out of your list. An IPv4 address is four numbers separated by dots, and each of those four numbers, called an octet, has to fall between 0 and 255. So 192.168.1.1 is valid, 10.0.0.255 is valid, and 203.0.113.42 is valid. But 256.0.0.1 is not, because 256 is one past the ceiling for an octet. Neither is 192.168.1, which only has three numbers, nor 192.168.1.1.1, which has five.

This matters more than it sounds. Logs are full of near-misses: version strings like 5.4.0.18, build numbers, fragments where an IP got cut off mid-line, or an address fused to a timestamp with no space between them. A naive search-and-grab pulls all of those in. The extractor checks the four-octet structure and the 0–255 range on every candidate, so a string like 256.0.0.1 gets flagged as out of range instead of silently landing in your clean list and sending you chasing an address that does not exist.

A worked example: a log snippet to a unique list

Here is a small slice of an Nginx access log, the kind you would copy straight out of a terminal:

203.0.113.42 - - [13/Jun/2026:02:14:07] "GET /login" 401
198.51.100.9 - - [13/Jun/2026:02:14:08] "GET /login" 401
203.0.113.42 - - [13/Jun/2026:02:14:09] "GET /login" 401
10.0.0.5 - - [13/Jun/2026:02:14:11] "GET /health" 200
203.0.113.42 - - [13/Jun/2026:02:14:13] "POST /login" 401
198.51.100.9 - - [13/Jun/2026:02:14:15] "GET /admin" 403

Six log lines, but only three distinct machines are involved. Paste that block in, keep the dedupe option on, and the output collapses to:

203.0.113.42
198.51.100.9
10.0.0.5

Now the story is obvious. 10.0.0.5 is internal traffic hitting the health check, fine. The two public addresses, 203.0.113.42 and 198.51.100.9, are both grinding away at /login with 401s, and one of them just probed /admin. Six noisy lines became three IPs and a clear next step, which is to check those two addresses against your firewall.

Where this fits into real work

The reason I keep this tool one tab over is that the same operation answers a surprising number of questions. A few that come up constantly:

  • Reading access logs. Strip a few hundred log lines down to the handful of unique IPs behind them, then count how many requests each one made.
  • Finding the offending IP. When an alert fires, you rarely get a clean address. You get a paste from a dashboard, a Slack message, a stack of grep output. Drop it in, get the addresses, move on.
  • Security review. Pull the IPs out of an SSH auth trail or a firewall log and compare them against an allowlist or a threat feed. The validity column is handy here, because malformed entries in a log can be a sign of probing or a broken client.
  • Building blocklists. Once you have the unique list, export it as plain lines for an iptables script, or as a SQL IN clause to query a request table.

In every one of these, the deduplication is doing quiet but heavy lifting. A busy endpoint might log the same attacker ten thousand times. You do not want to scroll ten thousand lines. You want the one address, listed once.

Why local processing is the right default

Logs are sensitive. They often contain customer IPs, internal hostnames, session identifiers, and the shape of your infrastructure. Pasting that into a random website that ships it off to a server is the kind of small decision that turns into an incident report later.

This extractor runs entirely in your browser. The text you paste and any local file you drop in are parsed on the page with the File API, and nothing leaves your machine. That design is not a marketing line, it is what makes the tool usable for the work it is built for. You can extract IPs from a production log during an active investigation without first asking whether you are allowed to upload it, because you are not uploading anything.

The first time I used it on a real incident, I had a 40,000-line auth log and a vague report that "someone is brute-forcing us." I pasted the whole thing, kept dedupe on, sorted the output, and got back 38 unique source addresses. Two of them accounted for nearly every failed attempt. That took less time than writing the awk one-liner I would have otherwise reached for, and I did not have to remember the field offsets.

Cleaning the list before you ship it

Once you have the unique IPs, a little hygiene pays off. Copied web text and dashboard exports carry hidden whitespace and inconsistent formatting, so normalizing before you dedupe avoids the case where the same address appears twice because one copy had a trailing space. The extractor normalizes as it goes, but if you are stitching several sources together it is worth being deliberate about it.

If your downstream step is strict about formatting, run the result through the IPv4 Address List Validator to confirm every entry is well formed before it lands in a config file or a database query. And when you need an audit trail rather than just a working list, export the CSV or Markdown view with line numbers instead of copying only the final block, so you can trace each address back to where it appeared in the source.

The short version

An IPv4 address is four numbers from 0 to 255 separated by dots, and the extractor pulls every valid one out of a log or block of text and dedupes them, so you can see the unique IPs hitting your server instead of scrolling through raw lines. It validates the octet range, keeps malformed entries visible for review, and never sends your text anywhere. Paste, extract, export. That is the whole loop, and most days it is all you need.

Made by Toolora · Updated 2026-06-13