Can You Get an IP Address From an Image? What a Photo Really Reveals, and How IP-Logging Images Work

No. An image file does not contain the IP address of the person who took it, sent it, or posted it. There is no field for one in JPEG, PNG, HEIC, WebP or GIF, and nothing a camera or phone writes into a picture records a network address. If you have a photo on disk and want "the IP of the image", there is nothing to find.

What people are usually asking about is one of three other things. An image link can log the IP address of whoever loads it, which is how "IP logger" images and email tracking pixels work. A photo's EXIF metadata can contain the GPS coordinates of where it was taken, a far more precise leak than any IP. And an image hosted on the web sits on a server with its own address, which tells you about the host and nothing about the uploader. This post takes them in that order, including why Gmail, Apple Mail and Discord now fetch images on your behalf so a logger sees their address instead of yours.

An image link logs whoever fetches it

Every image on a web page or in an HTML email is a separate HTTP request. The browser reads <img src="https://example.net/i/cat.png">, opens a connection to that server and asks for the file. The server cannot answer without knowing where to send the bytes, so the request necessarily carries the client's source IP address, and the server writes it to its access log with the time, the path and the User-Agent header:

203.0.113.42 - - [09/Oct/2026:14:02:11 +0000] "GET /i/cat.png?u=7f3a HTTP/1.1" 200 8812 "-"
  "Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148"

That is the whole trick. An "IP logging image" is an ordinary picture served from a host whose owner reads the log. The ?u=7f3a part is a per-recipient token, so the owner knows which recipient loaded it. A tracking pixel is the same thing shrunk to a 1x1 transparent GIF. Services like Grabify wrap it in a short link that records the hit and redirects to a real page, with optional JavaScript fingerprinting that only runs if the target opens the link in a browser.

What the logged address actually says

Here is the part the "IP puller" tutorials skip. An IP address identifies a network attachment point, not a person and not a building. A lookup on a typical fixed-broadband address returns this, trimmed to the fields that matter:

{
  "connection": {
    "asn":          3215,
    "organization": "Orange S.A.",
    "type":         "isp"
  },
  "location": {
    "city":    "Lyon",
    "country": { "code": "FR" },
    "region":  { "code": "FR-ARA" }
  },
  "security": {
    "is_proxy": false,
    "is_tor":   false,
    "is_vpn":   false
  }
}

City, region, country, the ISP and its autonomous system number, and whether the address is a known VPN exit, proxy or Tor relay. No name, no street. The city is the one assigned to the ISP's block, right most of the time on fixed lines. On mobile networks it is often the carrier's packet gateway, hundreds of kilometers from the phone, behind a carrier-grade NAT address shared by hundreds of subscribers at once. If the recipient was on a VPN, the log holds the provider's exit on a hosting network, and the lookup says so.

What the sender hopes to get	What the log and a lookup actually give
A home address	A city, sometimes a postal area, assigned to the ISP's block. Getting from there to a door requires a subpoena to the ISP.
The exact device	A user-agent string: browser family and OS version, nothing unique. Mail proxies replace it anyway.
A permanent identifier	An address that gets reassigned, shared behind CGNAT, or belongs to a VPN. Residential IPv4 is stable for weeks or months, not forever.
Proof that one specific person opened it	Proof that some client fetched the token: possibly a mail scanner, a link-preview bot or a proxy.

None of this makes IP logging harmless. City plus ISP plus timestamp is enough to tell which of two suspected accounts belongs to someone, or to follow a target across pseudonyms. It is just a much smaller thing than the map pin people picture.

Mail clients and chat apps fetch the image for you

The technique works less and less because the biggest clients stopped letting your device make the request. The server still gets a log line. It records the proxy.

Gmail went first. On December 12, 2013, Google announced that Gmail would display images by default and "serve all images through Google's own secure proxy servers". Filippo Valsorda tested it the same day: the request hit his server only when he opened the message, and it came from google-proxy-66-249-88-131.google.com with a generic user agent and "(via ggpht.com)" appended. Open tracking survives, since the per-recipient token still arrives at open time. IP tracking does not: a lookup on that proxy address returns AS15169, Google LLC, connection type hosting, and says nothing about the reader.

Apple went further. Mail Privacy Protection, announced on June 7, 2021 with iOS 15, "masks their IP address so it can't be linked to other online activity", and Apple's Mail documentation says remote content is "privately downloaded in the background when you receive a message (instead of when you view it)". That breaks open tracking too, because every message looks opened the moment it lands.

Discord has done this since before it was fashionable. Its November 14, 2017 engineering post on the Media Proxy gives the reason in half a sentence: "Linking directly to images would leak users' IP addresses to image hosts", the other half being bandwidth. Every image embed in a channel is fetched by Discord's servers, resized, and served from Discord's own domains, more than 150 million resizes a day back in 2017.

Link previews split three ways. In a 2020 study, Talal Haj Bakry and Tommy Mysk found that iMessage, WhatsApp and Signal build the preview on the sender's device and ship it inside the message, so the recipient's phone never touches the link. Discord, Slack, Twitter, Facebook Messenger and Zoom build it server-side. Two apps they declined to name built it on the receiver's device, handing the recipient's IP to the link's owner the instant the message arrived, no tap required.

The protection has edges. Tapping a link opens a browser, and the browser connects directly; proxies cover rendering, not clicking. Thunderbird with remote content allowed for a sender, self-hosted webmail without a proxy, and a URL pasted out of Discord into a browser all fetch from your own address. And Gmail's "ask before displaying external images" is a stronger setting than the proxy, because the request never happens at all.

The GPS in the file is the real location leak

Now the inverse case, which is worse and gets less attention. A photo straight off a phone with location services on carries an EXIF segment, and inside it a GPS sub-directory holding the coordinates of the shutter press. The fields are defined by the CIPA DC-008 Exif standard and listed tag by tag in ExifTool's GPS table: latitude and longitude as degrees, minutes and seconds with a hemisphere reference, plus altitude and a GPS timestamp. Phones write the seconds with decimals, so the stored value lands within a few meters of wherever the fix was.

Whether that block survives sharing depends on the path the file takes. Instagram, Facebook and X re-encode uploads, so the copies other users can download carry no GPS, although the originals reach their servers first. WhatsApp and Telegram strip it from compressed photos and keep it when you send the file as a document. Signal strips it before sending. Email attachments and iMessage photos arrive exactly as sent. Discord said in January 2018 that it strips "EXIF geocoding data mostly", and third-party tests since then disagree about files downloaded as attachments, so test it with your own photo before relying on it.

On iPhone, the share sheet has had an Options control with a Location toggle since iOS 13, on by default and reset for every share. The safer habit is to strip the file before it leaves your hands. Our image location anonymizer shows every field in a JPEG or PNG and removes them in the browser without re-encoding the picture. (If a photo exported from a social app comes back clean, that is expected; test with an original from your camera roll.)

Finding the server behind an image

The third meaning is the literal one. An image URL has a hostname, the hostname resolves to an address, and that address belongs to whoever hosts the file:

dig +short images.example.net
198.51.100.17

Look it up and you get a CDN, an object store or a bulk host: AS13335 Cloudflare, AS16509 Amazon, a rack in Frankfurt. That is the right place to send an abuse report, and it says nothing about who uploaded the file, since a consumer platform serves a million accounts' pictures from the same edges.

What to do on each side

If you are worried about being logged, let a proxying client render images for you and stop tapping shortened links from people you do not trust; Grabify-style links are clicks, and no proxy covers a click. Strip EXIF from any photo you post outside an app that strips it for you.

If you run a platform, proxy user-submitted images the way GitHub, Discord and Gmail do, so one member of a forum cannot harvest another's address by posting a picture, and re-encode uploads so EXIF goes with them. When you have a legitimate reason to log an address, a fraud review or an abuse report, resolve it to the signals you need (ASN, connection type, anonymizer flags, country) and keep those rather than the address. The Double Counter breach this month is what a 27-million-row archive of raw IPs and cities looks like when it leaks.

Ipregistry is the lookup step in all of this: give it an address from a log and it returns the ASN, connection type, city and the VPN, proxy and Tor flags that tell you whether you are looking at a reader, a mail proxy or a hosting box. You can try the API with 20,000 free lookups to get started.