Is This Link an IP Grabber? How to Check a Suspicious Link Before You Click

August 31, 2026 | 16 min read | Security
Home / Blog / Is This Link an IP Grabber?

Here is the most common way people get this wrong. Someone sends you a link. It feels off, so you do the responsible thing: you paste it into a malware scanner. Ninety-something security engines report it clean. You exhale and click.

That clean verdict is the wrong answer to the right question, and the reason is structural. An IP grabber is supposed to scan clean. It hosts no malware. It steals no password. It exploits no browser bug. It runs a plain web server that writes down who visited and then sends you where you were going. Reputation engines are built to answer "will this damage my device or steal my credentials?" You asked "will this tell the sender who and where I am?" Those are different questions with different tests, and only one of them has a scanner.

This guide is the other test. Four checks, roughly ninety seconds, none of which require clicking the link — plus the part almost nobody covers: how to check a link without handing your IP address to it in the process of checking. Along the way we probed the live infrastructure behind the biggest public logger services to show you exactly what their responses look like on the wire, because the popular advice about "following the redirect" fails against half of them.

Why the Scanner Said "Clean"

Google's Safe Browsing service is the engine behind the red interstitial warnings in Chrome, Safari, and Firefox. Its threat lists are public, and they sort dangerous URLs into a fixed set of buckets: malware, social engineering, unwanted software, and potentially harmful applications.

Read that list again and notice what is missing. There is no category for "records your IP address." There cannot be one, because every web server records visitor IP addresses. This page did. The server logs for the site you visited before this one did. If Safe Browsing flagged IP logging, it would have to flag the entire web.

5 billion+
devices are protected by Google Safe Browsing, by Google's own count — enormous coverage, aimed at a threat model that does not include tracking links. Coverage is not the problem. Category is.

Multi-engine aggregators inherit the same blind spot. VirusTotal describes itself as an aggregator of third-party antivirus products and URL/domain blocklisting services. A "0 vendors flagged this" result is a statement about what those blocklists contain. It is not an analysis of what the page does.

A clean malware scan on a tracking link is not a false negative in the scanner. It is a correct answer to a question you did not ask. The scanner said the link probably will not hurt your computer. You wanted to know whether it will identify you.

There is one useful thing a scanner still gives you, and most people skip past it: the final URL field. VirusTotal and similar tools follow the link server-side and report where it landed. That single field is worth more to you here than the verdict, and it costs you nothing, because their server made the request instead of yours. Which brings us to the part that matters most.

The 90-Second Check (Without Leaking Your Own IP)

The single biggest mistake in every "how to check a suspicious link" guide on page one of Google is that they tell you to expand the shortener yourself. Install this extension. Run this curl command. Hover and preview it.

Think about what those instructions actually do. A URL shortener cannot tell you where it points without you asking its server. Asking its server means opening a TCP connection to it. Which means handing it your IP address, your user agent, and a timestamp — which is the entire payload the grabber wanted in the first place. You did not avoid the trap. You walked into it politely and without seeing the destination page.

The fix is simple and it is the whole trick: make somebody else's computer do the fetching.

Three Ways to “Check” a Link — and Who Ends Up With Your IP 1. You click it Your browser your IP Logger server 302 Real destination Logged: your IP, city, ISP, browser, OS, exact time 2. You expand it yourself (curl, extension, hover preview) Your machine your IP Logger server You never saw the page but it still has your IP Same result. No benefit. 3. A server-side scanner fetches it for you Your machine URL only Scanner (their datacenter) their IP Logger server Logged: a datacenter IP in Virginia. Not you.

Step 1: Read the host, not the URL

Find the text between https:// and the very first single slash. That, and only that, is who controls the page. Everything after the slash is decoration written by the same person.

# The host is the part in bold-equivalent position. Everything else is theater. https://secure-paypal-verify.click/paypal.com/login ← host is secure-paypal-verify.click https://grabify.link/a1b2c3?ref=youtube.com/watch ← host is grabify.link https://www.paypal.com/signin?country=US ← host is www.paypal.com

This sounds obvious until you see it in a chat window at 11pm on a phone screen that truncates the URL after thirty characters. Mobile is where this check fails, and mobile is where these links are sent.

Step 2: Expand it with a third party's server

Submit the URL — do not open it — to something that fetches server-side and gives you a report:

One real risk with public scanners. urlscan scans submitted as public are searchable by anyone, and its API documents public, unlisted, and private visibility levels for exactly this reason. Security researchers routinely mine public urlscan results. If the link you are checking contains a password-reset token, an invite code, or a session identifier, submitting it publicly hands that token to strangers. Mark it unlisted, or use a different tool.

Step 3: Read the body, not just the headers

This is where most tools — and most advice — quietly fail, and it is the single most useful thing in this article.

A normal URL shortener answers with an HTTP redirect. Ask TinyURL for a link and you get a 301 and a Location: header naming the destination. Anything that follows redirects can see that. But an HTTP redirect is not the only way to forward a browser. A page can return a perfectly ordinary 200 OK with an HTML body containing a <meta http-equiv="refresh"> tag or a JavaScript location.href assignment, and the browser will move along just the same.

A header-following unshortener sees a 200 with no Location header and concludes: no redirect, this is the destination. That is a false negative, and it is not hypothetical — it is what the largest public logger services actually do.

What We Measured Probing Live Logger Domains

To make sure this article was describing 2026 and not a blog post from 2019, we probed the endpoints directly on 31 August 2026. Method: a single HTTPS GET to a deliberately non-existent tracking code on each domain, from a server, with a desktop Chrome user agent, recording the status line, headers, and body. No links were created and nothing was clicked. Here is what came back.

Domain probed HTTP status Redirect mechanism Caught by a header-only check?
tinyurl.com (normal shortener, control) 301 Location: header Yes
bit.ly (normal shortener, control) 301 Location: header Yes
grabify.link 404 (HTML, 13.8 KB) Server-rendered page Inconclusive
iplogger.org 200 (HTML, 65 KB) meta refresh + JS location.href No
yip.su 200 (HTML, 7.4 KB) meta refresh + JS location.href No
cliip.net (our own IP Logger) 301 / 302 Location: header Yes
Direct HTTPS probes, 31 August 2026. Status codes reflect responses to non-existent codes; live tracking codes behave the same way structurally. iplogger.org and yip.su are operated as alternate domains of the same service.

Two findings matter here.

First: the 200-with-a-body pattern is real and it defeats naive checkers. On both iplogger.org and yip.su the response carried no Location header at all. The forwarding logic lived in the page: a meta http-equiv="refresh" tag and a JavaScript timer that sets location.href after 3,000 milliseconds. That three-second pause is why these links feel like they "load slowly" before jumping. It is not slowness. It is the window in which the page runs.

Second, and more interesting: what runs in that window. The JavaScript served on the iplogger.org page referenced RTCPeerConnection (the WebRTC API that can reveal a real IP address from behind a VPN), navigator.geolocation (precise device location, which requires a browser permission prompt), toDataURL (canvas fingerprinting), and navigator.getBattery. The lighter yip.su page referenced none of them.

To be precise about what that measurement does and does not prove: it shows the page ships code capable of querying those interfaces. It does not prove every value is collected and stored on every visit. But it does tell you the surface area is far wider than "they get your IP," and it explains a red flag you should treat as decisive: if a redirect page asks your browser for location permission, close the tab. Browser geolocation uses GPS and nearby Wi-Fi networks, not your IP address, which means it is accurate to a matter of metres and a VPN does not protect you from it. The permission prompt is the only thing standing between that page and your actual address, and it only takes one distracted tap.

A third, quieter finding: grabify.link, iplogger.org, and yip.su all resolved into AS13335 — Cloudflare — when we ran the resulting addresses through our own lookup engine. That has a practical consequence. If you look up the IP behind a suspicious domain and the answer is a CDN, you have learned nothing about the operator, and you should not read it as reassurance. It is the expected result. Our own tracking domain resolves to a hosting provider in Ashburn, Virginia, and that tells you nothing about us either. You can try this on any address with our IP lookup tool or check domain registration with our WHOIS lookup, but treat the result as one weak signal, not a verdict.

The commands, if you want to run them yourself

Two requests, both halves of the check

# 1. Headers only — catches classic 301/302 shorteners curl -sIL -A "Mozilla/5.0" "https://short.example/abc" \ | grep -iE '^HTTP|^location' # 2. Body — catches the meta-refresh / JS forwarders that step 1 misses curl -s -A "Mozilla/5.0" "https://short.example/abc" \ | grep -oiE '<meta[^>]*refresh[^>]*>|location\.(href|replace)[^;]{0,60}'

Run these from a VPN, a cloud shell, or a throwaway VPS — never from your home connection. Both commands make a real request to the endpoint. If it is a logger, it now has whatever address you ran them from. This is the same trap as clicking, just with better posture.

What Grabber-Class Links Actually Look Like

Most articles hand you a list of logger domains and call it a day. Lists are worth something, so here is one — but read the caveat under it, because the list is the weakest tool in this article.

Domain family Notes (verified 31 Aug 2026)
grabify.link Live. The best-known consumer logger; also offers a pool of themed custom domains so the link you receive frequently does not say "grabify" anywhere.
iplogger.org, iplogger.com Live. Uses the 200 + meta-refresh + JS pattern described above.
2no.co, yip.su, iplis.ru Live. Alternate short domains of the same operator as iplogger. All three answered on probe.
blasze.com / blasze.tk Did not complete a TLS connection on probe. An old favourite that appears on every stale blocklist and no longer works — which is exactly why blocklists mislead.
cliip.net Live. Ours. Links from our IP Logger use this domain. It answers with a plain HTTP 302 and a Location header, so a single headers-only request exposes it.
Public logger domain families. This list is a snapshot and will rot; treat it as illustrative, not exhaustive.

Yes, we put our own domain on that list, and it belongs there. We run an IP Logger — the same class of tool, viewed from the creating side rather than the receiving side. It is used for legitimate things: verifying that a supplier who claims to be in Rotterdam actually is, knowing when a client opened an invoice, running a canary tripwire on a document. It is also, unavoidably, capable of the thing you are worried about right now.

We publish exactly how to catch our own links because a tracking tool that only works against people who don't know how to check isn't a security product. It's a trick. If you want the creator's-side view of what we're describing here, that's how IP loggers work.

Why domain lists lose, and what to use instead

Every serious logger service now offers custom or rotating domains, precisely because blocklists exist. The moment a domain gets flagged by enough platforms, the operator moves. Checking a link against a list you found in a blog post is a race you cannot win.

Mechanism signals age much better. Rank these:

Strong signals (any one is enough to not click)

  • A redirect that has no reason to exist. The destination is a public YouTube video, an image, or a news article. There is no campaign to track, no character limit to beat, no analytics team. Someone shortened a link that did not need shortening. Ask why.
  • The page asks for location permission. Decisive. Nothing legitimate about a redirect needs GPS.
  • A pause before it forwards you. Two to five seconds of "loading" on a link that ultimately just goes somewhere else is script execution time.
  • It arrived in a DM, right after a disagreement, from someone who has expressed curiosity about where you live. The social context is data. Weigh it.
  • The sender pushes back when you say you'll check it first. Nobody with an innocent link cares if you scan it.

Weak signals (suggestive, not conclusive)

  • A short random token of five to eight characters. So does every legitimate shortener.
  • A domain you have never heard of. So is most of the internet.
  • The link preview card fails to render in Discord or on X. Common for loggers, but also common for sites that block bot user agents.
  • The WHOIS record is privacy-protected. That is now the default for the overwhelming majority of domain registrations.
A note about "IP grabber checker" sites. Search that phrase and you will find pages offering to test a link for you. Judge them by one thing only: does the fetch happen on their server or in your browser? A tool that opens the link in an iframe, a preview pane, or a browser extension is making the request from your machine and delivering your IP address to the endpoint you were trying to avoid. The report has to come back from a datacenter, or it is not protecting you.

One more risk that gets no coverage: short URL token spaces are small enough to enumerate. Georgiev and Shmatikov's "Gone in Six Characters" (2016) demonstrated that six-character shortener tokens can be scanned in bulk, exposing content the creators assumed was private. The implication for you is that if a logger uses short tokens, the record of your visit may be discoverable by people other than the person who sent it.

What a Logger Captures — and What It Can't

Both directions of exaggeration are common here. "They can find your house" is wrong. "It's just a number, who cares" is also wrong. Here is the honest inventory.

One Click on a Logger Link: The Full Inventory CAPTURED PASSIVELY — no JavaScript needed • Your public IP address • Internet provider + ASN / network owner • Approximate area (city-ish, often wrong) • Connection type: home, mobile, hosting • VPN / proxy / datacenter flag • Browser, OS, device class (User-Agent) • Language (Accept-Language) • Where you came from (Referer) • Exact timestamp of the click IF JAVASCRIPT RUNS • Screen size, timezone, fonts • Canvas / WebGL fingerprint • Real IP via WebRTC, even behind a VPN NOT CAPTURED NOT POSSIBLE FROM A LINK CLICK • Your name • Your street address or apartment • Your phone number or email • Files, photos, messages, contacts • Camera or microphone • Your MAC address (never leaves your LAN) • Access to any of your accounts BLOCKED BY THE PLATFORM • Your IP, if you used a VPN or Tor • Email pixel opens in Gmail (image proxy) • Email pixel opens in Apple Mail (relay) Precise GPS: only with your permission tap.

The part people underestimate

The IP address alone is low resolution. Its value goes up sharply when it is combined with something. If someone already believes you live in a particular metro area and the click confirms it, that is corroboration. If two links sent through two different channels are clicked from the same address, that links two identities. If someone in a small town gets a hit that geolocates to that small town, statistical accuracy stops being the point.

The click record itself is often the real prize, not the geography. In an argument, a scam negotiation, or an ex's messages, the useful fact is frequently just you opened it, at 11:42pm, from a phone.

The part people overestimate

Location precision. IP geolocation resolves to your provider's routing infrastructure, not your home, and it is wrong far more often than marketing pages admit — we published the real accuracy figures by country and connection type in our geolocation accuracy breakdown. On mobile it is worse: carrier-grade NAT means hundreds or thousands of subscribers share one public address, and it commonly resolves to a regional gateway city rather than yours. "They have my IP" on cellular data is closer to "they have my carrier's gateway."

Email tracking pixels also fail far more often than senders think. Gmail routes remote images through Google's own proxy servers, so a pixel in a Gmail message records Google's infrastructure, not you. Apple's Mail Privacy Protection preloads images through Apple's relay, which breaks both the IP and the open time. If someone tells you they tracked you through an email image, there is a good chance they tracked Apple.

And fingerprinting is a genuine risk but an old one, not something this link invented. The EFF's foundational study "How Unique Is Your Web Browser?" found that 83.6% of browsers tested carried a unique fingerprint. Every ad network on the web has been doing this for fifteen years.

What Someone Can Actually Do With Your IP Address

This is the question underneath the question, so here it is ranked by how often it actually happens rather than how alarming it sounds.

1. Look up your rough area and your provider — the usual outcome

They paste it into a free lookup and get a region, a provider name, and a map pin somewhere in the vicinity. This is the ceiling for the overwhelming majority of cases, and it is where the story ends.

2. Confirm that you clicked, and when

Frequently the actual objective. Proof of engagement, with a timestamp.

3. Correlate you across links and accounts

Two links, two supposed identities, one address. This is how the "is my ex running this anonymous account" question gets answered — and it works in both directions.

4. Improve a phishing attempt against you

Knowing your provider and metro area makes a fake "your Xfinity account in Denver has been suspended" message meaningfully more convincing. If a link click is followed by a suspiciously well-targeted email, treat it as connected and work through our phishing investigation checklist.

5. Flood your connection (DDoS) — real, but narrow

This is the genuine risk, and it concentrates almost entirely on gamers, streamers, and people in competitive online communities. Paid "booter" services sell it by the minute, and the market is live enough that police keep having to knock it down: Europol's Operation PowerOFF shut down 27 DDoS booters in December 2024 ahead of the Christmas attack season, two years after the same operation took down the most popular platforms then in business. They come back every year. What a home DDoS does: knocks your connection offline for as long as somebody keeps paying. What it does not do: get into anything.

6. Scan your router for open ports

Only matters if you have exposed something. Default admin credentials on the router, a port-forwarded game or media server, UPnP opening ports you never audited. If none of that applies, a scan finds a closed door.

7. Contribute one piece to a doxx

An IP address is not a dox. Combined with a username, a school name, a photo with a recognisable background, and a public friends list, it narrows a search. The severe end of this — including a swatting case that ended in a death and a 20-year federal sentence — is documented in our article on how IP grabbers work. It is rare, and it is not what happens after most link clicks.

What an IP address does not give anybody: access to your accounts, your messages, your camera, your files, or your device. There is no "hack the IP" step. An IP address is a delivery address for network packets, not a key.

On the legal side: someone sending you a tracking link is generally not committing a crime, because logging a visitor's address is ordinary server behaviour. What they do with it afterwards is where the statutes engage — we walked through the actual frameworks, with section numbers and case law, in is IP tracking legal.

You Already Clicked. Now What.

Most people reach this article after the fact. Start here: nothing you do will delete the log entry. The request happened, the row was written, and there is no undo. That is fine. What matters now is the downstream, and for the large majority of readers the correct action is genuinely "nothing, carry on."

Work down this ladder and stop when it stops applying to you.

After the Click: Triage Ladder Work downward. Stop at the first rung that does not apply to you. 1 Did anything actually happen after the click? No threats, no outage, no odd emails → you are done. Someone has a guess at your city. Close the tab. 2 Did the page ask you to log in, or did you enter anything? That is phishing, not IP logging. Change that password now and enable 2FA. Different problem, much worse. 3 Did you tap “Allow” on a location prompt? Revoke site location permission in browser settings. That prompt gives metres, not miles — and a VPN never covered it. 4 Are you a gamer / streamer, or is harassment likely? Rotate your IP, then keep a VPN on for contact with that person. Harden the router while you are there. 5 Threats, extortion, or your connection is being attacked? Preserve evidence, do not reply, report to the platform and to IC3.gov. Call your ISP — only they can filter upstream. Most readers stop at rung 1. That is not complacency — it is the accurate threat model.

How to actually change your IP address

Advice on this is full of folklore. The realistic version:

Worth doing regardless, and rarely mentioned: change the router's admin password from the default, turn off remote administration, disable UPnP if you don't specifically need it, and apply the firmware update your router has probably been ignoring for two years. A leaked IP address is only interesting to an attacker if it points at something exposed. This is the step that actually reduces risk, and it takes ten minutes.

If it escalates

Screenshot everything before anything gets deleted: the message, the sender's profile, the full link, and any threats that followed. In the US, report to the FBI's Internet Crime Complaint Center and to the platform where it happened. If your connection is being flooded, your provider is the only party with the ability to filter it upstream — consumer routers cannot stop a DDoS, because the traffic has already consumed your line by the time it arrives. Do not reply to the sender, and do not send a tracking link back; that swaps you from complainant to participant, and it is the mistake that turns a one-sided harassment report into a mutual dispute.

Frequently Asked Questions

Usually not, and that is by design rather than a failure. URL reputation engines classify links as malware, social engineering, or unwanted software. Recording a visitor's IP address is none of those — every web server does it. A tracking link that hosts no malware and steals no credentials is expected to come back clean. Use the scanner for its "final URL" field, which shows you where the link resolves without your machine making the request, and ignore the verdict for this particular question.
No. An IP address resolves to an approximate area and an internet provider, not a street address, and on mobile connections it frequently resolves to a carrier gateway a long way from where you are. Only your internet provider holds the record connecting an address to a subscriber account, and disclosing it normally requires legal process such as a subpoena or court order. The one exception is not the IP at all: if you tapped "Allow" on a browser location prompt, that uses GPS and nearby Wi-Fi networks and is accurate to a matter of metres.
In most cases sending it is not itself a crime, because logging the address of someone who loads a page is ordinary server behaviour. What gets prosecuted is what happens next: using the address to launch a denial of service attack, to stalk, or to harass. In the EU and UK an IP address is personal data, so collecting it without a lawful basis or a privacy disclosure is a data protection violation rather than a computer crime. Our breakdown of what the law actually says covers the specific statutes and case law.
Only if you expect follow-up harassment or a denial of service attempt, which mainly affects gamers and streamers. Most residential addresses are dynamic, so powering the modem down for ten to fifteen minutes can release the lease and produce a new one, though many providers will simply hand back the same address. On mobile, toggling airplane mode is faster and more reliable. For everyone else the practical answer is that someone now has a rough guess at your city and your provider, and nothing further happens.
For link-based loggers, yes — the logger records the VPN exit server instead of you. Two gaps remain. WebRTC can expose your real address through the browser even while a VPN is connected unless you disable it, and we found RTCPeerConnection referenced in the JavaScript served by at least one major logger service. And a page that asks for and receives browser location permission bypasses the IP address entirely, because it reads GPS and Wi-Fi positioning. Our VPN detection guide explains what a VPN does and does not hide from the other side.
It depends entirely on where the request originates. A checker that fetches the link from its own servers protects you. A checker that opens the link in your browser, in an iframe, or through a browser extension makes the request from your machine and hands your address straight to the endpoint you were trying to avoid. Prefer established scanners that publish a server-side report, and never submit a link containing a password reset token or session identifier to a scanner whose results are public and searchable.
No — that is the design. A tracking link is supposed to deliver you to a real, innocuous destination, because a link that went nowhere would be reported immediately. The whole mechanism is a logging hop that you pass through on your way to a genuine page. Arriving at a normal YouTube video tells you nothing about whether the intermediate hop wrote down your address; only the redirect chain does.

See exactly what that link would have recorded

Run a lookup on your own address and read the same output a logger sees — provider, network owner, connection type, and how far off the location estimate actually is for you.

Look Up My IP Address

How we tested: the redirect-mechanism and domain-status results in this article come from direct HTTPS requests made on 31 August 2026 from a server, using a desktop Chrome user agent, against non-existent tracking codes on each domain. No tracking links were created and none were clicked. Network ownership was resolved with our own lookup engine, which is backed by a commercial-grade geolocation database.

Sources: Google Safe Browsing threat lists, Google Safe Browsing, VirusTotal documentation, urlscan.io API documentation, Georgiev & Shmatikov, "Gone in Six Characters" (2016), Eckersley, "How Unique Is Your Web Browser?" (EFF), Google (Gmail image proxying), Postmark (Apple Mail Privacy Protection), Europol (Operation PowerOFF, December 2024), and Europol (global DDoS-for-hire crackdown).

Need more lookups? View Pricing