The Form Was Encrypted. The Visit Wasn’t: What Your ISP Sees During an Adult Age Check

The page loaded just far enough to show the video thumbnail before an age-verification screen covered it. My choices were a facial estimate, a photograph of government ID or a card-based check. I opened a private window, pasted the address and tried again. The same screen appeared. Then a less obvious concern replaced my irritation: even if the verification company protected the information I submitted, could my internet provider still see that I had visited an adult site and contacted its age-checking service?

That question has become much more common in the UK. Strong age checks for services carrying pornography and certain other material considered harmful to children took effect in July 2025. By June 2026, Ofcom reported that most of the UK’s most popular pornography services had either introduced age assurance or blocked UK visitors. (Ofcom)

VPN use rose sharply as the checks appeared. (Ft) Some adults wanted access to blocked pages. Others were more concerned about the new trail created by the process: a connection to an adult website, followed by a connection to a facial-analysis company, identity provider or payment processor.

The confusion was visible in public privacy discussions too. People often treated three separate questions as one: whether an ISP could read the verification form, whether it could identify the services involved and whether the completed check could connect an online account to a real identity. (Reddit)

I had made the same mistake. The padlock in the browser made the whole visit feel private. In reality, it protected only part of it.

HTTPS protects the form, not the entire journey

The reassuring part is simple.

When an age-verification service uses HTTPS, the information exchanged with it is encrypted. The ISP cannot normally read the passport image, inspect the selfie, see the card number or learn whether the provider returned an “over 18” result. It also cannot read the exact page address or the content carried inside the connection. (IETF)

But the ISP still carries the traffic to its destination.

Without a VPN, it can see the network addresses contacted, when those connections occur and how much data moves through them. Ordinary DNS requests may reveal the domain being requested, while other parts of the connection can expose enough information to identify the service.

That creates an important distinction:

The ISP may not see what you submitted, but it may still see which companies your device contacted.

In the verification flow in front of me, the browser first contacted the adult website and then opened a separate connection to an age-verification provider. The contents were encrypted, but the sequence remained visible enough to be suggestive: adult site, verifier, return to the original page.

Encrypted DNS can hide the initial domain lookup, and newer encryption standards can conceal more of the connection setup. (IETF) They still do not place the complete browsing session inside a private tunnel.

Once I understood that, the problem stopped being theoretical. I was not worried that the ISP could read my ID number. I was worried that it could see the shape of the visit without needing to read it.

Private browsing removed the local evidence, not the network evidence

My first instinct had been to use a private browser window because it was familiar.

That helped with the laptop. The visit would not remain in the ordinary browsing history. Existing cookies were less likely to connect the page to another session. Someone using the computer later would not find the site by pressing the back button.

None of that changed the broadband connection.

The ISP still carried the traffic, and the adult site still received the household’s public IP address. Private browsing had cleaned the room without closing the curtains.

I enabled encrypted DNS next. That hid the normal DNS request from the ISP’s resolver, but the browser still connected directly to the website and its verification provider. I had removed one clue while leaving the route intact.

I could not observe my ISP’s internal logging or traffic-classification rules. It might retain the connection information, process it automatically or ignore it. What mattered was that the access network still had enough information to associate my line with the relevant destinations.

That changed what I was looking for. I did not need another browser setting. I needed the ISP to see one encrypted connection instead of the entire sequence behind it.

My usual VPN added another account before solving the problem

A VPN changes that sequence.

Instead of the ISP carrying separate connections to the adult site, the verifier and the services behind them, it carries an encrypted tunnel to the VPN endpoint. The websites beyond that tunnel are no longer presented as separate destinations on the household connection.

I already had an account with a large, established provider. It had years of public history, a substantial support operation and a long list of locations. It seemed like the obvious choice.

Then I opened the app and discovered that I had been signed out.

Getting back in required my email address, a password reset and a trip through the inbox. None of those steps was alarming on its own. Together, they felt poorly matched to the problem. I was trying to reduce the number of records attached to a private browsing decision, not reactivate another identity-based account before I could begin.

I considered a free browser extension instead. It would have taken less than a minute to install, but its permissions page gave me no quick answer about who operated it, what traffic it covered or how the service was funded.

I closed that too.

By then, the useful comparison was no longer free versus paid or large versus small. It was how much information and effort each option demanded before it protected the connection.

The smaller app reduced the journey to one visible connection

OnlydogVPN was already installed from an earlier travel test. It had fewer locations than the major service, a shorter public history and fewer independent ratings. Those are fair limitations.

Its advantage appeared before I connected: basic use did not begin with a conventional email-and-password registration.

I opened the app, chose the situation-based option for a difficult connection and connected. There was no account recovery, country map or protocol menu to work through.

Then I returned to the browser.

The age-verification screen was gone.

The thumbnail became a playable video, and the rest of the page finished loading normally. There was no card check, no facial estimate and no identity-document upload. More importantly for the question that had brought me here, the ISP no longer carried separate visible connections to the adult site and its verifier. It saw the encrypted connection to the service.

The app uses HTTP/3-based transport with additional obfuscation. In practical terms, that gave me a route that did not require protocol experiments or a series of server changes. I chose the situation and returned to the page.

The result was cleaner than the verification flow and faster than recovering the major VPN account.

I had not submitted age evidence to another company. I had not reconnected a long-standing VPN login to the session. And the access provider could no longer see the downstream sequence of sites involved.

That was the actual privacy improvement: not making the internet connection disappear, but making what the ISP could infer from it far less specific.

The next tab exposed the quieter traffic around the page

After the video started, I opened a related article in another tab. A blocked-request counter in the app began to increase.

The age-verification provider had been the obvious third party. Advertising, analytics and tracking systems were the quieter ones. As I moved between pages, the service filtered a number of those background requests before they completed.

That did not change the original result, but it answered a smaller concern created by the experience. Once I had started thinking about who could observe the age-checking journey, it became difficult to ignore all the other companies invited into an ordinary page load.

The counter made that traffic visible without requiring another privacy audit.

So, can your ISP see that you used an age-verification service?

Without a VPN, it usually cannot read the encrypted information submitted to a secure age-verification form. It does not see the passport image, facial scan, card details or verification result.

It may still see that the device contacted an adult website and then connected to a recognisable verification service. The sequence, timing and destination information can reveal the nature of the visit even when the form itself remains unreadable.

Private browsing protects the device history. Encrypted DNS hides one part of the lookup process. Neither conceals the complete route from the ISP.

The large VPN could have created the tunnel, but first it wanted me to recover another identity-based account. The free extension was quick but too opaque to trust. The smaller app asked for less, connected immediately and reduced the visible journey to one encrypted route.

For this problem, protecting the contents of the age-check form was only half the job.

The more useful privacy gain was preventing the ISP from seeing that the verification journey had started at all.