Email has no built-in way for a sender to know whether you opened a message. Tracking pixels are the workaround. They rely on one ordinary feature of HTML email: a message can contain images that are not attached to it but fetched from a web server when the message is displayed. Whoever runs that server gets to watch the fetch happen.
The mechanism in one request
When a company sends a newsletter, its mailing software adds a small image tag to the HTML of each copy. The tag looks something like this:
<img src="https://mail.example.com/open/8f3a91c7e2.gif"
width="1" height="1" alt="">The image itself is nothing: a single transparent pixel. The interesting part is the address. The string 8f3a91c7e2 is different in every copy that goes out, and the sender's database records which recipient and which mailing each one belongs to.
When your mail app displays the message, it requests that address the same way a browser requests any image on a web page. The server sends back the pixel and writes a line in its log. Because the address is unique to your copy, that line means “this person opened this message”.
Nothing about this needs the image to be tiny or invisible. A logo, a banner or a product photo served from a per-recipient address does exactly the same job. “Pixel” describes the usual disguise, not the technique.
What the sender learns
An image request carries the same information as any other web request. From one open, the sender's server can record:
- That the address is real and read. For a legitimate newsletter this is a statistic. For a spammer it is confirmation that your address is worth sending more to, or selling.
- When you opened it, and each time you opened it again.
- Your IP address, which points to your network and a rough location. The guide on what your IP address reveals covers how much that is.
- Your mail app and device type, from the User-Agent header the app sends with the request.
There is a less obvious case too. If you forward the message and the pixel goes along with it, the next person's open is logged against your identifier. The sender sees a second open from a different network and can reasonably guess the message was passed on.
What it cannot tell them
A pixel reports that the image was fetched. It does not know whether you read the text, how long the message was on screen, or anything else on your device. It cannot run code, read other mail or see your contacts. It is a web request and nothing more.
The signal is also less reliable than senders would like. Some mail services fetch images through their own servers instead of letting your device do it, so the sender sees the service's address and not yours. Some mail apps download remote content for every message in the background, whether you open it or not, which makes every message look opened and the time of opening meaningless. In those setups an “open” says very little about you.
Settings that stop it
The fix is the same everywhere: don't fetch remote images unless you choose to. The pixel only works if the request is made.
- Turn off automatic image loading. Almost every mail app and webmail service has a setting along the lines of “ask before displaying external images” or “block remote content”. With it on, messages show a placeholder and a button to load images for that one message.
- Load images per message, not per sender, when you have the choice. “Always show images from this sender” is convenient, and it turns tracking back on for everything that sender mails you.
- Read in plain text if your app offers it. Plain text has no images at all. Heavily designed mail becomes ugly, but nothing is fetched.
- Use your mail app's privacy mode if it has one that routes image requests through a proxy. This hides your IP address, though the fetch itself still happens.
Once you block images, you will notice which senders depend on them. Mail from a person is nearly always readable without. Marketing mail often is not, which tells you something about what it was built for.
Links are tracked separately
Blocking images does nothing about link tracking. In most marketing mail the links don't point at their real destination. They point at the sender's server with an identifier in the address, and that server logs the click and redirects you on. You can often see this by hovering over a link and reading where it really goes: a long address on a domain that is not the one named in the text.
A click is a much stronger signal than an open, because you had to do it yourself. If you want what the message is offering without reporting the click, type the site's address into your browser and find the page from there.
Read receipts are a third, older mechanism. They work through a header that asks your mail app to send a notification back, and most apps ask you first or ignore the request. They are easy to refuse and rarely used outside office mail.
What this site's inbox does
The disposable inbox here does not load remote images, and there is no button to turn them on. Before an HTML message is displayed, it passes through a sanitizer in your browser that removes every image tag, along with video, audio, embedded frames and objects, forms, scripts, style sheets and inline styles. A tracking pixel written as an image tag is gone before the page is drawn, so the request is never made. The cost is that messages look plainer than the sender intended.
Links are kept, because confirmation links are usually the reason you wanted the message. They open in a new tab. If a link is a tracked redirect, clicking it tells the sender you clicked, the same as in any mail app.
Blocking images is one layer
Turning off remote images stops the quiet kind of tracking, the kind that happens just because you looked. It does not change what a sender already knows: your address, and whatever you gave them when you signed up. For signups you don't expect to hear from again, the cleaner answer is to never hand over a real address, which is what a disposable address is for. For mail that has already arrived and looks suspicious, the guide to reading email headers shows how to find out who really sent it without loading anything in it.