Can a VPN Provider See Your Passwords? The Question I Asked Before Typing Mine

At 11:43 p.m., an age-verification screen appeared between me and a discussion thread I needed before morning. I blamed stale cookies, opened a private window and switched from home Wi-Fi to mobile data. Nothing changed. I downloaded a well-known VPN, connected, and reached my email login to retrieve a verification code. Then I stopped with the cursor in the password box: had I just routed the password that unlocked half my life through a company I barely knew?

The question behind the question

That hesitation is becoming more common.

When the UK’s age-check requirements took effect in July 2025, daily use of VPN apps rose sharply. Ofcom later reported that activity had roughly doubled at the peak, while noting that it could not reliably distinguish children bypassing restrictions from adults trying to avoid another identity check.

Research into the same period found a large jump in UK searches for VPNs and a parallel rise in public discussion. People were not only asking how to reach a blocked page. They were also asking what information a VPN could see, whether it created a new privacy risk and whether avoiding one identity check meant trusting another company instead.

That was the real problem in front of me.

I had installed unfamiliar network software in a hurry because the alternative appeared to involve submitting personal information to an age-verification service. The VPN had removed one obstacle, but it had also placed a new company in the path between my device and the internet.

The first provider seemed like the safe choice. It had a familiar name, years of public history, a polished app and far more independent discussion than most smaller services.

Then it asked me to create an account with an email address and another password before I could properly test the connection.

That request was not unusual. It was still enough to change the question I was asking.

There were really two questions:

Could the VPN read the password I entered on another website?

And:

How much identifying information did the VPN itself require before it would let me connect?

Public discussions about VPNs often circle around the same confusion. People understand that HTTPS is supposed to protect a login page, but they are unsure whether a VPN somehow opens that protection, reads the contents and seals it again.

It does not normally work that way.

What the VPN can see

When a website uses HTTPS correctly, the password entered into that website remains encrypted between the browser and the website.

The VPN creates an encrypted route from the device to the VPN server. Inside that route, the browser still creates its own secure HTTPS connection to the destination. The VPN carries that connection, but it does not ordinarily receive the website’s encryption keys.

A useful way to picture it is a locked envelope travelling inside a private delivery van.

The VPN operates the van. It can see that a delivery is taking place, where the van needs to go and how large the package is. It does not automatically have the key to the envelope inside.

That means a provider may be able to observe connection information such as timing, traffic volume and the service being contacted. It should not be able to read the password typed into a properly protected HTTPS page merely because the traffic passes through its server. TLS 1.3, the modern standard behind HTTPS, is designed to keep that content visible only to the two endpoints: the browser and the website.

This answered the question that had frozen my cursor.

The password for my email account was not being handed to the VPN in readable form.

But that answer did not make every VPN app equally trustworthy.

The warning signs that still matter

HTTPS cannot protect a password from everything happening on the device.

I would stop immediately if a VPN asked me to install an unexplained root certificate, security certificate or device-management profile. A trusted certificate can allow software to inspect connections that would otherwise remain encrypted. Android’s own security documentation explains how applications rely on trusted certificate authorities, including certificates installed by a user or administrator.

A browser certificate warning deserves the same reaction. It may indicate a configuration error, security software interfering with the connection or someone attempting to replace the secure connection.

The app itself also matters. Malicious software does not have to break HTTPS if it can record keystrokes, alter the page on the screen or steal credentials stored on the device. That is why downloading a VPN from an unofficial source is a very different risk from using a legitimate app that simply transports encrypted traffic.

The destination website can also see whatever is deliberately submitted to it. HTTPS protects the journey; it does not hide a password from the service receiving the login.

And there was one much simpler issue: the VPN provider could obviously receive the password I created for the VPN account itself.

If I reused a password from email, banking or work, the technical protection around the other login page would not save me from my own reuse. The provider would not need to intercept anything. I would have handed it the credential directly.

That was where the established provider began to feel mismatched to the immediate problem.

I had started with an age gate that wanted more personal information than I wished to provide. My proposed solution was now asking me to create another identifiable account before I could find out whether it even worked.

Trying the option with fewer disclosures

I closed the first app and installed OnlydogVPN.

The difference was not dramatic. That was part of the appeal.

I opened it, selected the connection suited to what I was trying to do and returned to the page. There was no conventional email-and-password registration screen between installation and the first test.

The age gate was gone.

I opened my email provider directly, confirmed that the address used HTTPS and that the browser showed no certificate warning, and typed my existing password. The verification message arrived. I copied the code, returned to the thread and finished the task that had started the whole search.

Only after the page loaded did I notice what had not happened.

I had not created another reusable password. I had not attached a fresh VPN account to my email address. I had been able to judge the connection before giving the service another piece of identity.

That does not make account-free access a substitute for trust. OnlydogVPN has a shorter public history, fewer ratings and less independent scrutiny than the established provider I tried first. For software that handles network traffic, that remains a meaningful limitation.

But it solved the privacy problem I was actually facing.

The familiar provider’s strength was its history. The smaller app’s strength was that I did not have to create another identity trail before learning whether the route worked.

The distinction mattered because the password inside the HTTPS connection had never been the main disclosure. The new account outside that connection was.

What appeared after the main problem was solved

Once the thread was open, I continued browsing and noticed a blocked-request counter increasing.

The service includes filtering for advertising and tracking requests. Fewer of those requests meant less background activity following the page load. It did not make me invisible, remove information I deliberately submitted or replace the protection provided by HTTPS.

I could see the counter and the difference in page behaviour, although I could not independently inspect every internal filtering rule.

Still, the benefit followed naturally from the reason I had installed the app. I had started because I did not want to provide more identity than necessary. Reducing some of the advertising and tracking traffic on the next pages addressed a smaller version of the same concern without requiring another setup step.

It was not the reason my password stayed unreadable.

HTTPS did that.

The filtering simply gave me another reason not to delete the app as soon as the original page opened.

The distinction I wish I had understood sooner

A VPN provider occupies an important position in the connection, but that does not mean it can automatically read every piece of information moving through it.

On a correctly secured HTTPS page, the password remains encrypted between the browser and the website. The VPN transports that encrypted session. It does not normally open it.

The more useful questions are practical ones:

Did the browser show a valid secure connection?

Did the VPN request unusual certificates or device-control permissions?

Was the app installed from a legitimate source?

What information did the service ask me to provide directly?

That final question changed the comparison.

The established provider offered the comfort of a longer public record. It also required an identifiable account and another password before I could evaluate the connection. The smaller service had less public history, but it let me complete the immediate task without creating another credential.

For this situation, minimal identity collection mattered more than another polished account system.

The VPN was not reading the password I typed into the secure website. The more avoidable risk was being asked to invent one more password for the VPN itself.