Before you finished your coffee this morning, you were IP-logged somewhere between twenty and a few hundred times. Every website you opened recorded your address. So did the sites whose ads and fonts and analytics scripts loaded in the background without you ever seeing their names. If you opened an email with its images on, the sender almost certainly logged you too. None of it required a click on anything labelled "logger," and none of it is a breach. It is simply how the web works.
That is the part most explanations of "IP logging" skip, and skipping it is why the topic feels murkier than it is. People picture a hacker-ish trap, a special link that "steals" your IP. That thing exists, but it is a narrow and noisy corner of a much larger, mostly dull reality: logging an IP address is the default behaviour of every server on the internet, built in, on by default, and running right now.
This article separates the dull default from the deliberate trap, shows you exactly what a logged IP does and does not expose, puts real accuracy numbers on the location question, and walks through the single most famous case of an IP logger catching someone — the FBI's 2007 bomb-threat investigation — with the caveat that case usually gets stripped of. If you want to watch it happen on your own address rather than read about it, you can run our IP lookup at any point and see the same fields a logger sees.
In this article
- The two things people call "IP logging"
- What a single HTTP request actually exposes
- The three mechanisms: logs, links, and pixels
- Observed facts vs. what the client just tells you
- What a logged IP can — and can't — reveal
- How common is this, really
- Who logs IPs, and why
- Is IP logging legal?
- Case study: the fake news link that caught a bomb threat
- See it on your own connection
- Frequently asked questions
The Two Things People Call "IP Logging"
Search "IP logging," "IP logger," and "IP grabber" and you will get the three terms used as if they were interchangeable. They are not describing three different technologies. They are describing one technology pointed in two different directions, and the direction is the whole story.
Here is the axis that actually matters. Not the tool — the targeting.
- Passive logging records everyone who connects to a server, indiscriminately, as an automatic side effect of running the server. The site owner did not do anything to log you specifically. You are line 4,812,009 in a text file alongside every other visitor.
- Targeted logging is bait built to capture one specific person. Someone stands up a resource they control — a redirect link, an invisible image — and delivers it to a chosen target so that when that person loads it, their address lands in a log the sender is watching. This is what people usually mean by an "IP logger link" or an IP grabber.
The machinery underneath is nearly identical. A web server writes down who connected. The difference is who gets caught in the net and whether it was aimed. Confusing the two is how you end up either paranoid about ordinary web browsing or complacent about a link that was built specifically to find you.
What a Single HTTP Request Actually Exposes
To understand logging you have to understand what your browser hands over on every single request, before any tracking script runs, before you type anything, before cookies even enter the picture. Opening a connection to a server is itself an act of disclosure, because the server physically cannot reply to you without knowing where to send the reply.
The standard record of that disclosure is the access log. Apache and Nginx, which serve the large majority of the web, both default to a near-identical "combined" log format, and every mainstream host, CDN, and cloud platform produces an equivalent. One request becomes one line. Here is a real-shaped combined-log line with each field labelled:
Read left to right, a single uneventful request to a single page already reveals: the IP address the request came from; the exact time down to the second; the page requested; the HTTP status and byte size of the response; the referring page (where you clicked from); and the user-agent string naming the browser, operating system, and device class. This is documented behaviour, not a trick — see any plain-language access-log guide or the Nginx logging documentation, and note that managed platforms log the same fields: Amazon's S3 server access log format records requester IP, time, operation, and status in exactly this shape.
What's striking is how much of this is invisible to you as a visitor. You see a page load. The server sees a structured, timestamped, attributable record. Multiply that by every third-party resource embedded in a modern page — the analytics beacon, the ad exchange, the embedded video, the web font — and a single page view can quietly write your IP into a dozen different companies' logs, each on a server you never chose to visit.
The Three Mechanisms: Logs, Links, and Pixels
Essentially all IP logging happens through one of three mechanisms. The first is passive; the second and third are the toolkit of targeted logging.
1. Plain server logs (passive)
The default described above. The server records every request to a flat log file. The owner never sent you anything; you came to them. This is the overwhelming majority of all IP logging by volume, and the least interesting, because it is not aimed at anyone. It exists to debug outages, measure traffic, and — as the EU's top court explicitly blessed, which we will get to — defend against attacks.
2. Tracking / redirect links (targeted)
A short URL that points at a server the sender controls. When you open it, that server logs your request, then issues a redirect that forwards your browser to a harmless destination — a YouTube video, a news article, an image — so the hop feels like a normal link. As one plain walkthrough of the technique puts it, you get the target to click a link and the intermediate page quietly records where they came from. This is the classic "IP logger link." We break the receiving-side mechanics down further in IP tracker vs. IP logger vs. IP grabber.
3. The tracking pixel (targeted, no click required)
A one-by-one transparent image embedded in an email or a web page. It is invisible, but loading it is a request to the sender's server, so it logs your IP and user-agent and signals that the content was opened — all without you clicking a thing. This is the quiet workhorse of email open-tracking, and it is the reason "we see you opened our email" is a thing marketers can truthfully say. We cover its email-specific behaviour in the IP logger guide.
The critical thing about mechanisms 2 and 3 is that the redirect and the invisible image are misdirection, not capability. They do not add any power to the logging. They exist purely so the target does not notice the logging is happening. The actual data captured is the same access-log line as mechanism 1. If you want to see the creating side of mechanisms 2 and 3 for yourself, that is exactly what our IP Logger does: it generates a tracking link or an invisible pixel and shows you the visitor data each one records.
Observed Facts vs. What the Client Just Tells You
Here is the precision point almost every "IP logging explained" article gets wrong, and it changes how you should read any log. Not every field in that log line is equally trustworthy. Some are observed facts of the connection. Others are simply whatever your browser chose to say, and can be changed freely.
The IP address and timestamp are observed facts. The server read the source address off the actual network connection and stamped it with its own clock. You cannot fake those from your browser without routing through something else — a VPN, a proxy, Tor — which doesn't forge the address so much as substitute a different real one (the exit server's). Short of that, the IP in the log is genuinely the address your packets came from.
The user-agent and often the referrer are client-supplied. The user-agent is a string your browser volunteers, and anything that sends an HTTP request can send any string it likes. It is trivially spoofable — which is why the user-agent header is considered self-reported identification, not proof. A scraper can claim to be an iPhone; a bot can claim to be Chrome on Windows. Treating the user-agent as a fact is a classic analyst mistake.
Why does this matter for a real reader? Because it tells you precisely what a logged IP is good for and what it isn't. The IP plus the timestamp is a solid anchor: it is the thing law enforcement subpoenas a provider about, the thing a fraud team keys on, the thing that genuinely ties a connection to a network at a moment in time. Everything the client volunteered on top — the device, the browser, the referring page — is useful context and a liar's playground in equal measure.
What a Logged IP Can — and Can't — Reveal
This is where both the paranoid and the dismissive get it wrong. The logged IP is not a home address, and it is not "just a meaningless number" either. It is an approximate locator plus a reliable pointer to your internet provider. The key word is approximate, and the accuracy collapses the more precise you try to get.
The database industry is unusually candid about this. The leading commercial geolocation providers publish their own accuracy figures, and they are a ladder that falls off a cliff. Per the published geolocation accuracy figures from MaxMind, a major provider:
Region or state accuracy runs roughly 55–80%, varying heavily by country. City accuracy is the wild one: anywhere from about 20% to 75%, highest in large, dense cities on residential fixed-line connections, and poor everywhere else. The provider's own framing is the honest one: the output is "an approximate location, not a precise one." A logged IP gives you a dot on a map that is often the centre of a city or an ISP hub, not a pin on a rooftop. We go deep on why these numbers swing so much in how accurate IP geolocation really is.
The CGNAT problem: why mobile logging is especially blurry
There is a structural reason mobile IPs are nearly useless for pinpointing anyone, and it deserves its own paragraph because it quietly breaks a lot of naive assumptions. It is called carrier-grade NAT (CGNAT). Because the world ran out of IPv4 addresses, mobile carriers no longer give each phone its own public address. Instead, thousands of unrelated subscribers share a single public IPv4 at the carrier's gateway (the reserved 100.64.0.0/10 range in RFC 6598 exists specifically for this). The address a server logs is the carrier's gateway, not the device.
How badly does that distort location? A vivid illustration comes from a walkthrough of mobile CGNAT geolocation: subscribers physically in Kisumu (about 265 km from Nairobi) and in Mombasa (about 440 km away) can all "surface on the internet meters apart in the same Nairobi data center." Three people hundreds of kilometres apart, logged at the same point. If you have ever looked up a mobile visitor's IP and gotten a city they swear they've never been to, this is why.
How Common Is This, Really?
Passive logging is universal — because it is the default server behaviour, effectively every website on the internet logs visitor IPs. That is not a figure of speech; it's a consequence of how the protocol works. The more interesting question is how common targeted logging is in the one place it reaches you without a click: your inbox.
The best data here comes from a rigorous academic study, not a vendor blog. In "I never signed up for this!" (Englehardt, Han, and Narayanan, Proceedings on Privacy Enhancing Technologies, 2018), researchers analysed a corpus of roughly 12,600 mailing lists from about 900 senders. The findings, also reported by CSO Online, are stark:
Sit with that 30% for a second. In nearly a third of cases, simply opening the email — not clicking anything — handed the recipient's email address to an outside company, via a tracking pixel firing on open. That is targeted IP logging operating at industrial scale, inside a channel most people treat as private. The single most effective defence is unglamorous: stop your mail client from auto-loading remote images.
Who Logs IPs, and Why
Logging has a reputation problem because the one dramatic use case — someone trying to find you — crowds out the mundane majority. Here is the honest spread of who does it and why.
| Who | Why they log IPs | Passive or targeted |
|---|---|---|
| Every website operator | Debugging, traffic analytics, abuse prevention, and — per the EU court — defending against cyberattacks | Passive |
| Marketers & analytics | Measuring campaigns, attributing conversions, and confirming email opens via pixels | Both |
| Security & fraud teams | Rate-limiting, blocking attackers, flagging logins from unexpected networks, detecting VPNs and proxies | Passive |
| Law enforcement | Attributing a connection to a subscriber via the provider, under legal process | Both |
| Individuals | Verifying a contact's claimed location, catching a catfish, or — the abuse case — trying to locate someone | Targeted |
| Scam-baiters | Volunteer communities who turn loggers back on scammers to gather location evidence | Targeted |
The individual use cases are where legitimate and abusive blur, and it's worth being plain about it. Confirming that a supplier who claims to be in Rotterdam is actually connecting from the Netherlands is reasonable. Sending a stranger a disguised link to find out where they live is the behaviour regulators and courts care about. The tool is the same; the context is everything. Our practical walkthrough of the legitimate side is how to track an IP address — including what you genuinely can and can't learn.
Is IP Logging Legal?
Short version: yes, logging is legal everywhere, but in Europe it is regulated, and the legal status of the address itself differs sharply between the EU and the US. This is general information, not legal advice, but the landmarks are clear.
The EU: an IP is personal data, and logging needs a basis
The defining case is Breyer v. Germany (C-582/14), decided by the Court of Justice of the EU in October 2016. The court ruled that a dynamic IP address recorded by a website operator is personal data in that operator's hands — but only if the operator has a legal means to identify the visitor using additional information the internet provider holds. In the same ruling, and just as importantly, the court found that a website operator has a legitimate interest in storing IP addresses to protect its systems against cyberattacks. The official CJEU press release on Breyer lays out both halves.
That dual holding is the whole EU framework in miniature: an IP can be personal data, and you are allowed to log it to defend yourself. GDPR codifies the first half — Recital 30 names IP addresses explicitly as "online identifiers" that can make a person identifiable. The practical upshot for anyone operating in the EU or UK: logging IPs is lawful, but you need a lawful basis (legitimate interest or consent), and you must treat the logs as personal data — retention limits, disclosure, the lot.
The US: log freely, but only the provider can name the subscriber
The United States takes a markedly different posture. There is no general rule against logging, and under the third-party doctrine, information you voluntarily hand to a third party — such as the subscriber details your ISP holds — generally does not carry Fourth Amendment protection. As a legal analysis of the doctrine explains, that means law enforcement can typically obtain the subscriber behind an IP by subpoena rather than a full warrant.
For the full statute-by-statute breakdown across scenarios — website logging, tracking links, workplace monitoring, and more — see our dedicated guide to whether IP tracking is legal.
Case Study: The Fake News Link That Caught a Bomb Threat
The most instructive real case of targeted logging is also the one most often retold inaccurately, so here it is with the caveat intact.
In June 2007, someone using an anonymous MySpace profile sent a string of bomb threats to Timberline High School in Lacey, Washington, forcing repeated evacuations. The suspect was careful: he routed his connection through proxy servers, which defeated ordinary passive logging. The school's and the platform's logs would only ever show the proxy, not him. This is exactly the scenario passive logging cannot solve — the observed IP was a real address, just not his.
So the FBI switched from passive to targeted. Agents created a fake news link — a counterfeit Associated Press / Seattle Times story about the threats — and sent it to the suspect's MySpace account. When he clicked it, FBI software called CIPAV (the Computer and Internet Protocol Address Verifier) reported his real IP address and location back to investigators, cutting straight through the proxies. According to the documented account of CIPAV, the tool captured the IP address, MAC address, open ports, running programs, operating system, installed-application info, the default browser, and the last URL visited — then logged outbound IP addresses with timestamps.
The trail led to Josh Glazebrook, a 15-year-old student at the school, who pleaded guilty to the bomb threats along with identity theft and felony harassment. The operation was first reported by Wired's Kevin Poulsen in July 2007 and is recounted in archived coverage from Governing and NPR.
That shared principle is the honest lesson. Passive logging failed against a careful suspect because he never connected to the investigators directly. Targeted logging worked because it made him come to them. The entire difference between the two halves of this article, demonstrated in a single investigation.
(Volunteer scam-baiting communities use the same get-them-to-click principle against scammers to gather location evidence. It's a real practice and a useful mental model for targeted logging, though reliable, citable accounts of specific unmaskings are thin on the ground — so treat the colourful war stories you'll read with caution.)
See It on Your Own Connection
The fastest way to make all of this concrete is to look at what a logger would see if you clicked. Three tools on this site let you do exactly that, from the safe side:
- Run an IP lookup on your own address. You'll see the same fields a logger captures — provider, network owner (ASN), connection type — and, crucially, how far off the location estimate is for your specific connection. On mobile, watch how far the "city" sits from where you actually are.
- Create a link or pixel with the IP Logger. This is the creating side of mechanisms 2 and 3. Generate a tracking link or an invisible pixel, load it yourself, and read back the visitor record it produced. Seeing the capture from the operator's chair is the single clearest way to understand what the receiving side is exposed to — and it's the honest way to learn the limits, since you'll see it records an approximate area and a provider, not a name.
- Check whether a VPN actually hides you with the VPN detector. Turn a VPN on, then test: if your connection flags as a datacenter or VPN address, the mask is working and any logger will record the exit server instead of you. If it still shows your home provider, your VPN is leaking.
None of these do anything to anyone else. They point the same lens the rest of this article described back at your own connection, which is the only IP you're entitled to inspect freely.
Frequently Asked Questions
See exactly what a logger would record about you
Run a lookup on your own address and read the same fields a logger captures — provider, network owner, connection type, and how far off the location estimate actually is for your connection.
Look Up My IP AddressA note on our tools: the IP lookup and IP Logger on this site resolve network and location data using a commercial-grade geolocation database. The accuracy limits described above — strong at country level, far weaker at city level, and especially blurry on mobile — apply to every geolocation provider, ours included.
Sources: Last9 (access-log format), Edge Delta (Nginx logging guide), AWS (S3 server access log format), How-To Geek (tracking links), Wikipedia (User-Agent header), MaxMind (geolocation accuracy figures), Ipregistry (mobile CGNAT geolocation), RFC 6598 (shared CGNAT address space), Englehardt, Han & Narayanan, "I never signed up for this!" (PETS 2018), CSO Online (email tracker reporting), CJEU (Breyer v. Germany press release), GDPR Recital 30, Lexology (third-party doctrine), Wikipedia (CIPAV), Governing (Timberline case), and NPR (Timberline case).