How to share a PDF without storing reader IP addresses

You want to know who read your document - who opened it, how far they got, whether the same person came back. Fair enough. But do you really want to keep a log of every reader's IP address to find out? Most document trackers make you do exactly that. It turns out you don't have to.

There is a quiet assumption baked into almost every "track who viewed your document" tool: that recognising a reader and recording their address are the same thing. They are not. You can build a perfectly useful picture of how a document is being read - returning readers, country, pages, time on each page - without ever keeping the one piece of data that turns a reader into a person on a map. This guide walks through why the IP usually gets stored, why that is a problem you inherit the moment you do it, and the cleaner approach FileDroppr uses instead.

Why traditional document trackers log IPs

When a reader opens a shared document, the only thing the server reliably sees is the network connection itself - and the IP address attached to it. So the easy way to tell one visitor apart from another is to write that IP down. It's already there in every request, it's roughly stable for a session, and it doubles as a crude location signal. That's why so many trackers store it: it is the path of least resistance to "the same person came back" and "this view came from this country."

There is also a feature pull. Storing the raw IP feels like it future-proofs your data: maybe one day you will want to cross-reference reads, block a specific visitor, or look up exactly where a view came from. So the address gets kept "just in case." That instinct is understandable, but "just in case" is precisely the kind of open-ended retention that data-protection rules push back against - and most of those hypothetical uses never actually happen.

The problem is that an IP address is not just a row in your database. It is a piece of information about a real person, and once you store it, it is yours to account for.

The privacy problem with IP-based tracking

Under the GDPR and the UK GDPR, an IP address is generally treated as personal data - information relating to an identifiable individual. The moment you store one, you have taken on the responsibilities that come with handling personal data. In broad terms that means you need a lawful basis for collecting it, you need to be clear about why you hold it and for how long, you are expected not to keep it longer than you need, and you can be asked to produce or delete it if the person makes a request. None of that is exotic - it is just the baseline for anyone holding data about people.

For a freelancer sending a proposal or a founder sharing a deck, that is a lot of obligation to sign up for in exchange for a stat you barely look at. And it compounds: every tool you use that quietly logs reader IPs is another place you now hold personal data, another retention schedule to think about, another data store that could be exposed. The surface area grows without you really choosing it.

There is a principle that runs through good data practice called data minimisation - the idea that you should only collect and keep what you actually need for the job at hand. If the job is "understand how my document is read," you do not need the reader's address to do it. The cleanest way to avoid the liability is therefore the simplest one: don't store the IP in the first place. You cannot leak, mishandle, or be compelled to produce data you never kept. (This guide explains the principles in general terms and is not legal advice.)

The alternative: pseudonymous reader identities

Here is the trick that makes "no stored IP" compatible with "I can still recognise a returning reader." Instead of saving the IP, you run it through a one-way function together with a secret value - a salt. A one-way function is easy to compute in one direction and effectively impossible to reverse: the same input always produces the same output, but you cannot work backwards from the output to the original input.

So an IP goes in, and what comes out is a fixed, scrambled fingerprint that looks nothing like an address - something the system then labels as a stable identity like Reader #214. Because the same IP always hashes to the same fingerprint, the next time that reader opens the document they map to Reader #214 again. You can see them return. But the actual IP was never written down, and because the function only runs one way - and the salt is secret - you cannot recover it from what was stored. The recognisable identity exists; the address that produced it does not.

The salt is what closes the obvious loophole. Without it, someone who got hold of the stored fingerprints could in theory hash every possible IP address and look for matches, since the range of addresses is small enough to grind through. Mixing in a secret salt before hashing breaks that attack: the fingerprints only make sense in combination with a secret that lives on the server and is never shared. The result is an identity that is stable enough to be useful to you and meaningless to anyone who might come across it.

What you can know - and what you can't

With pseudonymous identities you still get the things that actually matter for understanding how a document lands. You can see returning readers (Reader #214 came back three times), which country a read came from, which pages were read and how far people got, and how much time was spent on each one. That is enough to tell who is engaged and where attention drops off.

What you cannot know is the part that should make a reader comfortable: the actual IP address, because it was never stored, and the reader's real identity, because a pseudonymous ID is not a name. The only way a name enters the picture is if the reader chooses to give it - by typing an email into an optional gate before the document opens. Absent that, Reader #214 is just Reader #214.

That boundary is deliberate, not a limitation. Most of the time you do not need a name to make a decision. "A returning reader in Germany spent four minutes on the pricing page and came back twice" tells you what you need to know about interest and where attention is landing. If a specific deal genuinely calls for knowing exactly who is on the other end, the email gate gives the reader the choice to identify themselves - which is a very different thing from quietly harvesting an address they never agreed to share.

How FileDroppr implements it

FileDroppr is built this way from the ground up. Each reader is identified by a salted one-way hash of their IP, giving the stable Reader #N identity described above - so returning-reader detection works without a single address being saved.

Country attribution is handled the same careful way: the address is resolved to a country in-flight, during the request, and then discarded - the country label is kept, the IP is not. Files themselves are encrypted at rest with AES-256-GCM, and when a share link expires the encrypted file is swept off disk shortly after. The readership measurement is first-party - it happens inside the FileDroppr viewer - so there are no third-party tracking scripts riding along on your document. You can read the privacy details for the specifics.

Why this is better for everyone

For you, the sender, it means less to carry. There is no log of visitor IP addresses sitting in your account waiting to become a liability - nothing to justify a lawful basis for, nothing to hand over, nothing to remember to delete. You get the readership insight and skip the data-handling overhead that usually comes with it.

For the reader, it means being measured without being surveilled. Their reading behaviour helps you improve the document, but their address is never captured and their identity stays their own unless they choose to share it. That is a fairer deal than most trackers offer - and it is exactly why DocSend alternative searches often lead here: DocSend stores IPs, and FileDroppr does not.

It is worth saying plainly that you give up almost nothing for this. The metrics that drive real decisions - did they read it, how far did they get, did they come back, where did the read come from - all survive intact. The only thing that disappears is a column of raw addresses that was mostly a liability anyway. Privacy and insight are usually framed as a trade-off; here they point in the same direction.

Step by step: share a PDF without storing IPs

Upload your PDF at filedroppr.com - no account needed to try it.
Copy the share link (or grab the QR code or embed code) and send it however you normally would.
Open your readership report to see returning readers, country, per-page reading, and the read-through funnel - all without a stored IP behind any of it.
Optionally turn on the email gate (Pro) if you want an actual name attached to a read, set a password, or schedule the link to expire.