Anonymize IP addresses in a log file

Truncation zeroes part of each address. An IPv4 loses its last octet — 203.0.113.42 becomes 203.0.113.0, a /24 — and an IPv6 loses its last 80 bits, keeping the /48: 2001:db8:85a3::8a2e:370:7334 becomes 2001:db8:85a3::. This is the convention the nginx and Apache anonymizer modules and GDPR-motivated analytics tools popularized. It is irreversible, and it deliberately destroys correlation: two different visitors on the same /24 both collapse to the same truncated address, so you can no longer follow one client through the file. That is exactly what you want when the risk you are managing is re-identification in something you are handing to an outsider.

Tokenization replaces each distinct address with a stable placeholder — [IPV4-1], [IPV6-2] — assigned in first-seen order. The value is gone, but the identity survives: the same client is the same token on line 3 and line 900, so you can still see that one address hammered /login forty times or that two errors came from one visitor. Reach for this when you are debugging a traffic pattern with a colleague and correlation is the thing you need to keep, not destroy. The toggle changes only how IP addresses are replaced; switching it re-runs the file instantly.

It is worth being exact, because the word “anonymized” does a lot of quiet overclaiming in this corner of the internet. A truncated IPv4 still names a network of roughly 256 hosts, and a truncated IPv6 still names a /48. That is enough to resist casual re-identification and to break per-client correlation, which is a real and useful privacy gain — but it is pseudonymization, not strict anonymization, and it is certainly not a certification. This page describes the technique as “GDPR-style” truncation because that is the lineage of the method; it does not, and cannot, tell you that your output is GDPR-compliant. Whether truncated logs are lawful to share for your purpose, in your jurisdiction, is a legal determination that belongs to you and your data-protection advisor. The tool gives you a clean, honest transformation; the compliance judgment stays yours.

The engine does not parse nginx’s or Apache’s grammar and does not care which column an address sits in. It scans every line for the shapes of addresses and secrets wherever they appear — the client field, each hop of an X-Forwarded-For chain, a query string, a referrer URL, userinfo in a URL, or the free text of an error line. A custom or home-grown log format is scanned just as thoroughly as a standard one, so nothing escapes by living in a field a format parser would have ignored. IPv6 is handled in full, compressed ::, mixed-case, and IPv4-mapped (::ffff:…) forms; a zone id like %eth0 is dropped, since an anonymized address has no interface scope.

Because IP addresses and secrets share one detection pass, an access log’s other leaks get masked in the same run: an email address in a ?email= parameter, a session JWT in a callback URL, a Bearer token echoed into an error, a password= that ended up in a stack trace. Those are always replaced with deterministic tokens whichever IP mode you pick — an email in a query string must not survive into a log you are calling “anonymized.” Every distinct value keeps a stable token, so the file stays readable.

Pattern-based detection is incomplete by construction, and any tool that says otherwise is overpromising. It will not catch a customer name in a user-agent string, an internal account id with no telltale shape, a hostname that is just a word, or a secret split across two lines. The suspicious-string flagger is a safety net for random-looking values, not a guarantee, and it ignores runs shorter than about 20 characters. In the other direction it can over-mask: a four-part version string whose parts are all under 256 — 1.2.3.4 — is indistinguishable from an IP address and will be truncated, which is the safer failure. The side-by-side preview marks every changed and flagged line so the final human review — the step no tool replaces — takes seconds. Never treat any automated redaction, this one included, as complete.

This is a one-file, pre-share tool: you have a log in hand and you want it safe to attach before it leaves your machine. It is not a logging-pipeline processor — if you need IP anonymization applied continuously to a stream at ingest, that belongs in your collector or log shipper, configured once. Sharing a general log rather than anonymizing its addresses? The log file redactor masks the same emails, keys, and tokens with the IP addresses tokenized rather than truncated. Only want to know whether a file still has anything sensitive in it, without changing it? The secret scanner reports what it finds and leaves the file untouched.

Files are processed entirely in memory with a practical ceiling of about 20 MB; nothing persists after the tab closes, and the page works offline once loaded. A truncated or tokenized IP never changes the line it sits on except in place, so the file’s structure and line count survive intact and the output re-imports as the same log. If your log is larger than the ceiling, split it by day or by service and anonymize the slice you actually need to share.