Direct answer and scope

An internet service provider (ISP) can usually see information about your internet connections even if it cannot always read the actual content of what you send and receive. The key distinction is between (1) connection data, such as destinations, timestamps, and volumes, and (2) payload content, such as the exact text of a webpage or the media stream itself.

Because different networks and devices handle traffic differently, the exact visibility varies. Still, you can treat your ISP as most likely to observe connection metadata, while encryption commonly reduces what they can inspect inside the connection.

A simple model of what an ISP can observe

A practical way to understand ISP visibility is to separate your activity into three observable layers:

  1. Connection metadata (often visible):
  • The fact that your device opened network connections
  • Approximate timing (when connections start/stop)
  • Data volume (how much data is transferred)
  • Network destination information (for example, the remote server address or a category of destination)
  1. Traffic handling details (sometimes visible):
  • Protocols being used (e.g., whether the session is using common web or other transport patterns)
  • Performance-related characteristics (like throughput behavior), depending on how the ISP equipment is set up
  1. Content/payload (often not readable when encrypted):
  • The actual webpage text, chat messages, or media contents
  • The details of files transferred

When applications use encryption end-to-end (or at least encrypt the session from the client side), the ISP is frequently limited to the metadata above rather than being able to view the content itself.

Differences and important exceptions

Several factors can change what an ISP may see:

  • Whether traffic is encrypted: If a session is not encrypted, the ISP may be able to inspect more of the payload. With encryption, content is typically harder to read, but metadata can still be available.
  • Where encryption terminates: Even with encryption, the practical visibility depends on what is encrypted between your device and the remote service. If encryption ends early (for example, within some network path), more could become visible.
  • Non-web and special traffic patterns: Some services may fall back to unencrypted connections for certain parts, or use multiple connections where some are encrypted and some are not.
  • Your device and app behavior: If an app includes plaintext elements (for example, certain requests or telemetry) or uses mixed modes, an ISP could still see those unencrypted portions.

A useful caution: even if content is hidden, patterns in metadata can still reveal a lot—such as when you start using a service and how much data transfers during those times.

Practical checks you can do

You can validate your expectations with observations on your own device and browser:

  • Look for encryption indicators in the browser: Many browsers show a lock indicator for HTTPS connections. This does not prove everything end-to-end, but it helps you confirm that the web session is commonly encrypted.
  • Check whether the content you see corresponds to encrypted sessions: If a webpage loads without encryption indicators, assume more may be visible to intermediate networks.
  • Use connection-type expectations: If you know a service is supposed to be protected, verify whether your session appears to use encrypted transport.
  • Review what remains inherently visible: Even in encrypted scenarios, you should still expect the ISP to learn that connections exist, approximate destinations, and the amount of data transferred.