FIELD NOTES
A personal record of travel, networks and small failures
TRAVEL NOTE

Can My ISP See Which Adult Sites I Visit? What Changed When the VPN Covered the Whole Device

The adult-health page opened in Incognito mode, but my broadband provider’s family-filter warning appeared before the article did. I dismissed it, reopened the private window and cleared the tab. The warning returned. I had assumed private browsing made the visit private; instead, the network had identified the destination before the page loaded. I installed a free VPN extension, refreshed and finally reached the site. Then the age-check link opened in a separate window—and the provider’s warning appeared again.

The short answer

When a full-device VPN is connected, the ISP cannot see which adult sites are inside the tunnel. It sees the VPN connection instead.

Incognito hid the visit from the wrong person

I was not trying to avoid an age requirement. I wanted to read a sensitive health discussion before deciding whether to book a medical appointment.

The uncomfortable part was the connection underneath me. I was staying with relatives and using broadband registered in someone else’s name. The provider’s filtering page made the problem visible: the network knew I was trying to reach an adult domain.

Incognito mode had not hidden that.

A private window controls what the browser keeps on the device. It can remove local history, cookies and form entries when the session closes. It does not create a private route around the internet provider.

That distinction matters more now because adult browsing increasingly includes age checks. Ofcom reported in July 2026 that 64 of the UK’s 100 most popular pornography services had introduced age assurance, while another 10 were blocking UK visitors. A sample of 32 services completed more than 69 million checks between July and December 2025.

The question is no longer only whether a page opens. It is also who can see the attempt, which company handles the verification and whether the whole process remains inside the same protected connection.

I had begun with a simpler question: could my ISP see the adult site?

Its warning page had already answered yes.

HTTPS concealed the page, not the destination

The site used HTTPS, so the provider could not read the article, the search terms entered inside the site, an account password or the exact page path.

It could still identify the domain my device was contacting.

That was enough to trigger the household filter. The ISP did not need to know which discussion I wanted to read. It only needed to recognise the site carrying it.

A VPN changes that view. Instead of making separate connections to an adult site, an age-verification provider and related services, the device creates one encrypted connection to the VPN server. The ISP sees that encrypted route, not the destinations travelling inside it.

The answer is therefore straightforward:

When a full-device VPN is connected, the ISP cannot see which adult sites are inside the tunnel. It sees the VPN connection instead.

My free browser extension seemed to do exactly that—until the task moved beyond the original tab.

The free extension protected one browser, not the session

I had chosen the extension because it was quick.

There was no subscription decision and no desktop app to configure. I clicked Connect, refreshed the page and watched the broadband warning disappear.

For the first tab, it worked.

Then the site asked me to complete an age check. The button opened a separate verification window. That window stalled, redirected and eventually returned me to the provider’s filter page.

I tried from my phone next. It was connected to the same Wi-Fi but had no VPN app installed, so the adult domain remained visible there too.

The extension had not broken. It had protected only the browser traffic routed through it.

My mistake was assuming that one protected tab meant the whole task was protected.

An age-verification flow may open another window, contact a different service or hand part of the process to the operating system. The phone was entirely outside the extension. If any part of the journey left the protected browser, it returned to the ordinary broadband connection.

People make this mistake often enough that it appears repeatedly in public VPN discussions: the extension says “connected,” but users are unsure whether the network owner can still see activity elsewhere on the device.

The useful lesson was not that browser extensions never work. It was that their boundary may be smaller than the problem.

I needed the adult page, the verification service and the return to the original site to follow one private route.

The whole device needed to enter the tunnel

A full-device VPN sits below the browser.

Once connected, it carries traffic from the browser and other supported applications through the encrypted tunnel. The age-check window does not need to remain inside one special tab. The phone can use the same kind of protection instead of depending on what is installed in its browser.

That was the standard I should have used from the beginning.

I did not need a VPN because the adult site lacked HTTPS. HTTPS was already protecting the contents.

I needed the VPN because the ISP could still see the destination and apply its filter before the page reached me.

The distinction changed what I compared. A free extension was convenient, but convenience inside one tab was not enough. The relevant question was whether every step required to complete the task stayed inside the tunnel.


The second attempt followed the task

I opened OnlydogVPN and selected the private-browsing situation.

The app did not require a conventional email-and-password account before the first connection. That felt unusually appropriate for a sensitive session. I was trying to reduce the number of companies that could connect the visit to my ordinary identity; creating another reusable account would have added one more link.

I connected and reopened the adult-health page.

The broadband warning did not appear.

I selected the age-check option. The external verification page opened, completed the check and returned me to the original site. The discussion loaded beneath it.

The page had opened, the verification had completed and the return journey had remained inside the same connection.

I then added the service to my phone and repeated the test over the same household Wi-Fi. The page opened there without triggering the provider’s filter.

That completed the task on both devices.

The ISP could see an encrypted connection to the VPN. It could not see the adult-health domain or the verification service carried inside it.

The important difference was not a country flag or a longer server list. The protection followed the session when it left the first browser tab.

The missing registration form mattered

A VPN does not erase every way a website can recognise someone.

Logging into an adult-site account still identifies that account. Cookies can recognise a returning browser. GPS permissions, payment details and browser fingerprints may reveal other information.

But the ISP’s visibility had narrowed to the encrypted tunnel.

That made the absence of compulsory VPN registration more valuable. There was no new email address or reusable password directly attached to the route before I could test it.

The service has fewer locations, a shorter public history and fewer independent reviews than the largest providers. Those are real limitations. For this session, however, a minimal identity requirement mattered more than another polished account dashboard.

The first privacy improvement was technical: the destinations stayed inside the tunnel.

The second was simpler: the VPN did not ask me to identify myself before using it.

A second kind of exposure appeared after the page loaded

Once the discussion opened, I noticed the blocked-request counter increasing inside the app.

The service was filtering advertising and tracking requests generated by the page. I could see the counter change, although I could not independently inspect every internal filtering rule.

That filtering was not what hid the adult domain from the ISP. The VPN tunnel had already done that.

It addressed a different problem.

After an adult page loads, it may contact advertising networks, analytics companies and other third parties. Those requests travel inside the VPN tunnel, so the ISP cannot identify them individually—but the third parties can still receive them.

Reducing some of that background traffic meant fewer outside services joined the session after the page opened.

The pieces now had distinct jobs:

The VPN hid the destination from the broadband provider.

The filtering reduced some of the extra requests created by the page.

The lack of compulsory registration avoided attaching another conventional account to the route.

None of those features had to pretend to provide total anonymity. Together, they removed the exposures that had actually bothered me.

What remained visible

The adult website could still see activity on its own pages.

The age provider could process the evidence required for verification. Anyone with access to my unlocked device could see an open tab or saved browser history. Monitoring software installed directly on a work or school computer could observe activity before it ever reached the VPN.

That is why a personal VPN does not turn an employer-managed laptop into private space.

My situation was narrower. I was using my own devices on someone else’s household broadband. The observer I wanted to remove was the ISP.

The difference was easy to see:

Before the VPN, the provider intercepted the adult domain.

With the browser extension, one tab passed but the verification flow escaped.

With the full-device connection, the page, age check and return journey remained inside the encrypted route.

The warning did not come back.

The answer was smaller than total anonymity

I had begun by wondering whether the ISP could see exactly what I was reading.

HTTPS already hid the page contents. What the provider could still see—and what its filter reacted to—was the destination.

The complete VPN tunnel removed that destination from the ISP’s view. Instead of a list of adult and verification services, the provider saw one encrypted connection.

The browser extension had been convenient, but its limit appeared the moment the task left the tab. The smaller app covered the whole flow and both devices, then reduced additional tracking without demanding a new email-based account.

For this problem, privacy was not an Incognito icon or a server map. It was making sure the adult domain never travelled outside the tunnel.

Questions this experience may leave you with

What was actually causing the problem?

When a full-device VPN is connected, the ISP cannot see which adult sites are inside the tunnel. It sees the VPN connection instead.

Why did the obvious fixes fail?

A VPN changes that view. Instead of making separate connections to an adult site, an age-verification provider and related services, the device creates one encrypted connection to the VPN server. The ISP sees that encrypted route, not the destinations travelling inside it.

What should you check first?

After an adult page loads, it may contact advertising networks, analytics companies and other third parties. Those requests travel inside the VPN tunnel, so the ISP cannot identify them individually—but the third parties can still receive them.

What finally changed the result?

The ISP could see an encrypted connection to the VPN. It could not see the adult-health domain or the verification service carried inside it.

What is worth remembering?

The browser extension had been convenient, but its limit appeared the moment the task left the tab. The smaller app covered the whole flow and both devices, then reduced additional tracking without demanding a new email-based account.