What "No Logs" Really Means in a VPN

Open any VPN homepage and you will see the same two words near the top: “no logs.” It appears so often it has stopped meaning anything in particular. Every provider says it. The premium ones, the bargain ones, the ones with billboards in airports, the ones you have never heard of. They all say it. And yet the people saying it are running actual servers, on actual disks and memory, that process every packet you send through them.

So what does a VPN no logs claim actually mean, and how would you know whether it is true? This is the question the marketing copy never answers honestly. This post does.

The short version: “no logs” is a useful starting point, not a finish line. It covers a wide range of practices, some of which genuinely protect you and some of which are essentially marketing language wrapped around perfectly normal data retention. To evaluate it, you need to know what a VPN provider can see in the first place, what categories of logs exist, and the difference between a policy of not logging and an architecture that cannot log.

What a VPN Provider Can See

Before we talk about logging, we need to talk about visibility. Logging is a question of what gets written down. Visibility is a question of what is in front of the server in the first place. These are different problems, and conflating them is one of the main ways VPN marketing misleads people.

When you connect to a VPN, your device sets up an encrypted tunnel to one of the provider's servers. From there, the server decrypts your traffic and forwards it to the public internet. That decryption step is the whole point — it is how the VPN substitutes its IP for yours when your traffic reaches whatever site you are visiting. Our introduction to what a VPN is and how it works covers the underlying mechanics in more detail.

That arrangement, by itself, means the VPN server can technically observe:

• Your real IP address at connection time. Your device has to tell the server where to send the encrypted reply packets. That destination is your real IP.
• Which VPN server you connected to, and when. The server you picked, the timestamp you connected, the timestamp you disconnected. This is metadata about the session.
• DNS queries you made, if the VPN runs its own DNS resolver. When you type a domain into your browser, something has to look up the IP address. If your VPN resolves that for you, it sees the lookups.
• Bandwidth used per session. How many bytes moved in each direction.
• Traffic timing patterns. Even if the contents are encrypted to the destination site, the size and timing of packets can reveal information to a determined observer.

The encrypted contents of your HTTPS connections are not in this list. Once your browser is talking to, say, your bank over TLS, the VPN sees encrypted bytes going to your bank's IP, not the actual content. That part of the protection is real and important.

But the metadata above is real. It exists in memory while your session is alive, because the server needs it to do its job. The question of “logs” is what happens to that data afterwards — whether it gets written to disk, kept around, indexed, retained, and potentially produced later under legal pressure.

Categories of Logs

Not all logs are equal. A useful no logs VPN evaluation starts by distinguishing between three categories, because providers blur them on purpose.

Connection logs

These are minimal session metadata: a record that a user connected at some timestamp to some server, possibly with the session length and bandwidth used. Many providers keep some version of this short-term for diagnostics, anti-abuse, or capacity planning. A small number keep nothing at all.

Connection logs by themselves are not catastrophic. They do not reveal what you did. But they do reveal that you used the service, which can matter in some contexts, and they become much more revealing when combined with identifying account data.

Traffic logs

This is the category that should not exist. Traffic logs record which sites or IPs you visited, what your DNS queries were, and in extreme cases the URLs you requested. A VPN that keeps traffic logs is, from a privacy standpoint, worse than no VPN at all — you have concentrated the visibility of your browsing into one provider's database instead of fragmenting it across your ISP and the sites you visit.

No reputable VPN should keep traffic logs. If a provider's policy is ambiguous on this point, treat the ambiguity as a no.

Identifying metadata

This is the category most people forget about, and it is often where the real privacy story lives. It includes:

• The email address you signed up with
• Your payment method and billing details
• The IP address you signed up from
• Support tickets and the IPs they were sent from
• Any account recovery information
• Login timestamps and device fingerprints used for account security

Identifying metadata is your identity at the VPN. Even if the provider truly keeps zero traffic logs and zero connection logs, an email plus a credit card means they can answer the question “did this specific human being have an account with us?” — and that is often the only question anyone needs answered.

This is why a VPN no logs claim, on its own, is incomplete. A provider that keeps no logs but requires email-and-card signup has built its privacy story on policy, not architecture. The data still exists; it just lives in a different table. The same point shows up in our piece on anonymous VPN services without email.

Policy vs. Architecture

There are two fundamentally different things a provider can mean when they say they do not log.

“We do not log” is a policy claim. The systems are capable of logging. They might log temporarily, in memory, or in some support tool somewhere. The promise is that the company chooses not to retain that data, or chooses to discard it. This is a real promise and worth something — but it relies on trusting the company. Policies can change. Employees can make mistakes. Court orders can compel changes that are not advertised.

“We cannot log” is an architecture claim. The system was built so the data does not persist. Servers run from memory only and forget everything on reboot. There is no database table where the relevant information could be retained even if someone wanted it to be. Account creation does not require collecting identifying information in the first place. This is a much stronger claim because it does not depend on continued goodwill — the data is gone because there is no place for it to go.

Architecture is verifiable, at least in principle. Policy requires trust.

Most providers offer a mix. The marketing tends to describe policy promises in language that sounds architectural (“no logs servers,” “RAM-only infrastructure”). Read carefully. The question to ask is: if someone served this provider a legitimate legal request tomorrow demanding everything they have about a specific account, what could they actually produce? If the honest answer is “an email, a payment record, signup IP, support history, and possibly connection timestamps,” that is your privacy floor regardless of what the homepage says.

How to Evaluate a Claim

Here is a practical checklist for assessing what data a VPN collects and whether their claims are credible.

Independent third-party audit

Look for a published report from a reputable security firm that has reviewed the provider's systems, methodology, and infrastructure. Two things to check:

• Recency. An audit from four years ago describes a company that may no longer exist in the same form. Two years or newer is a reasonable bar.
• Scope. Audits vary enormously in what they actually examined. An audit of the no-logs policy is more meaningful than a generic security audit. Read the scope section of the report itself, not the summary on the VPN's blog.

Transparency reports and warrant canaries

Some providers publish how many legal requests for user data they receive each year, broken down by jurisdiction and type, and what they were able to hand over in response. A provider that publishes “we received N requests and produced data in zero of them, because we had nothing to produce” is making a stronger statement than one that publishes nothing.

A warrant canary is a periodic statement that the provider has not received certain types of legal demands. If the statement disappears or stops being updated, the absence itself is a signal. Canaries have known legal weaknesses, but their presence at least demonstrates that the provider has thought about this dimension.

Legal jurisdiction

The country a VPN is incorporated in determines whose laws apply to it and what international cooperation agreements it operates under. Some jurisdictions have mandatory data retention laws for telecommunications providers. Others belong to formal intelligence-sharing alliances that obligate cooperation across borders.

This is not a binary good-or-bad axis — different threat models care about different things. But it is worth knowing where your VPN is incorporated and what that implies, rather than picking by which homepage looks cleanest.

Account model

This is the one most people skip. Look at how you sign up. If creating an account requires a working email address, then the VPN has a working email address for you. If payment is by credit card, the VPN has a billing record tied to your name. These records are part of the privacy picture whether or not the provider “logs” anything else.

Anonymous payment options (gift cards, certain cryptocurrencies) shift this somewhat. Subscription models that rely on a platform identity you already have, like the Apple ID through the App Store, shift it differently: the VPN provider does not get your identity, but the platform does.

Open-source client code

If the app on your device is open source, security researchers can verify what it actually sends and to where. This does not cover the server side, but it removes one category of uncertainty: you can know whether the client is quietly phoning home with telemetry you did not consent to.

Closed-source clients are not automatically suspect, but they are less verifiable. Combined with the audit picture, open-source clients raise the floor of what you can independently check.

Past legal cases

If a VPN has been involved in legal proceedings where logs were demanded, the public record will show what happened. Did they produce data? Did they have data to produce? Did the response match their policy claims?

These cases are not common, but they are extremely informative when they exist. Search the provider's name plus “subpoena” or “court order” and read the news coverage rather than the provider's own framing.

A Simple Comparison Frame

Here is a compact way to look at the questions above:

Neither column is uniformly correct for every provider, and most operate somewhere in the middle. But mapping a given VPN onto this table is more useful than nodding at “no logs” on the homepage.

The Snap VPN Approach

Snap VPN sits closer to the architecture column than the policy column. Specifically:

• No email or account signup. The subscription is handled through the App Store via your Apple ID. We never collect an email address, a username, a phone number, or any account credentials. There is no account database in the conventional sense.
• No traffic logs. We do not record the sites you visit, the IPs you talk to, or the DNS queries you make.
• No persistent connection logs. We do not keep a retained record of which Apple ID connected to which server at which time. The operational state needed to route an active session is not the same as a stored connection history.
• No user identifiers tied to a real person. Internally, your subscription is identified by an opaque value provided by the App Store. We do not have a name, an email, or a phone number attached to that value, and we cannot derive one from it.

To be honest about what does exist: running a VPN requires some operational state. A server has to know there is an active session in order to route packets back to you. There are short-lived counters and metadata needed for the network to function at all, the way any router has to track active connections to do its job. This is what the connection-logs category in the taxonomy above actually looks like in practice: short-lived, scoped to the live session, not retained as a record of your activity, and not tied to anything that identifies you.

The principle behind these choices is mundane: less data collected is less data that can be lost, breached, or compelled. If a piece of information was never gathered, it cannot be exfiltrated in a breach, it cannot be subpoenaed, and it cannot be repurposed later when business needs change or someone acquires the company. Architecture beats policy not because policies are insincere, but because architecture removes the option.

If you want to dig into the account model specifically, see our explainer on anonymous VPN signup without an email address.

What No VPN Can Do

It is worth being explicit about the limits, because some of the trust that gets attached to VPNs is misplaced and ends up disappointing people who expected more than the technology can deliver.

• A VPN cannot hide you from sites you log into. If you open Gmail through a VPN, Google still knows you are you. You signed in. The VPN changes the route, not the identity.
• A VPN cannot stop browser fingerprinting. Sites build identifiers from your browser version, screen size, fonts, time zone, and a hundred other small details. A VPN does not address this layer at all.
• A VPN does not prevent malware. It encrypts your traffic; it does not inspect it for threats. Antivirus is a separate concern.
• A VPN cannot magically grant anonymity on services where you have already authenticated. Anonymity has to be designed in. If your starting point is an authenticated account, a VPN routes that account's traffic differently — that is the entire effect.

A VPN is one layer of a privacy stack, not the whole stack. Related reading: common VPN myths debunked, what a VPN actually is, and a broader iPhone privacy checklist for layering the rest.

Bottom Line

“No logs” is shorthand for a much larger conversation. When you see it on a VPN homepage, treat it as the headline, not the answer. The questions that actually matter are:

• What data does the system collect at all, including identifying metadata at signup?
• Of the data it collects, what does it retain, in what form, and for how long?
• Is the no-logs claim a policy (we promise) or an architecture (we cannot)?
• Has anyone independent verified the claim recently, and what did they actually examine?
• What is the provider's track record when legal pressure has been applied?

A provider that answers these questions in plain language, with a clear distinction between what they have promised and what their architecture makes impossible, is a provider you can reason about. One that gestures vaguely at “no logs” and changes the subject is not.

The reason this distinction matters is simple: privacy that depends entirely on a company's continued good behavior is privacy you do not fully control. Privacy that is structurally constrained, because the data was never collected in the first place, is the version that survives changes in ownership, jurisdiction, leadership, and legal climate.

Snap VPN was designed around that second idea. No email signup, no account credentials, no user identifiers tied to a real person. The subscription rides on your Apple ID through the App Store, the traffic is not logged, and the operational state needed to run the network is not tied to who you are. It is not the only way to build a VPN, and it does not solve every privacy concern. But it removes a class of risk that no policy promise alone can. If that is the kind of design you want behind your traffic, that is what is on offer here. Just an honest description of the choices we made and why.