A browser is not a VPN and does not hide your IP address. Tracking protection is list-based and not absolute: known ads, analytics, and social trackers from bundled lists are blocked on the device, but no blocker catches everything. Per-site exceptions exist when a page needs a blocked resource. Private Browser Incognito is rated 17+ for unrestricted web access and is intended for adults.
A page that never breaks under a blocker is a page the blocker barely touched. Real lists match real hosts. Sometimes those hosts also serve the player, the comments, the paywall, or the checkout script you came for. The honest product admits that collision and gives you a local way out: a per-site exception. This page is about that hole, why it exists, and what it is not. It is not a tour of button labels we are not sure of. It is not a claim that blocking is 100 percent when you leave the exception off.
Private Browser Incognito blocks ads, analytics, and social trackers with content-blocking rules powered by the open Disconnect lists. The lists ship inside the app and run on the device. They are not downloaded at runtime. The app does not sit in the middle of your traffic as a proxy, and it is not a VPN. For how those lists live in the binary, see On-Device Ad and Tracker Blocking on iPhone. For the gap no list closes, see Tracker Blocking Is Not Absolute. What follows is the exception itself.
Why a needed module can match a rule
A content blocker is a set of rules. A request is allowed or it is not, based on whether it matches. That is a sharp tool for names the list already knows. It is a blunt tool when one hostname does two jobs. Advertising networks and site furniture often share infrastructure. A video iframe, a comment count, a map tile, or a payment widget can live on a host the lists also use for ads. When the rule fires, that module never starts. The rest of the document may still paint. The part you needed does not.
We describe three buckets with generic labels. An ad request tries to load a creative or an auction. An analytics beacon reports that a page viewed. A social widget tries to attach a share button or a comment count from a network you did not open as the main page. Company names do not belong in the examples. If a request sits in those buckets and on the list, it can be stopped. If a needed script sits on the same name, it can be stopped too. That is not a secret failure. It is how list matching works.
First-party code is a different miss. If the script is served from the same site you opened, it may not look like a tracker. Sites fold analytics into their own origin because it survives blockers. Blocking can be true in the third-party sense and false in the “nobody learned that you loaded this” sense. The destination still learned it. Extra companies might not. An exception does not fix that first-party gap. It only lets listed names through for that site.
What an exception is, locally
A per-site exception is a local choice on that iPhone, in this app. It tells the blocker to stand down for that site so the page can finish. It does not report to us. There is no account and no app server for browsing. The App Store privacy label is Data Not Collected. Turning an exception on does not phone home. It does not disable tracking protection on other sites. It does not become a cloud preference you will find on a second device, because we do not sync.
Use exceptions sparingly. Finish the task. Erase if you do not want that site’s cookies to linger for the rest of the session. One-tap erase closes every tab and destroys cookies, cache, and site data. The exception is not a history file. Every tab is still a private session in memory. There is no browsing history feature. Allowing a broken checkout through does not write a Recents row. It does allow more third-party requests from that origin while the exception is in force.
We will not invent a button name, a settings path, or a shield badge we are not sure of. The product fact is that exceptions exist. The product limit is that we will not document a click path that might be wrong by the next release. If the page you needed still fails after you allow the site, the failure may be first-party, a changed host, or something lists never covered. Treat the exception as a hole in a known set, not as a repair shop for the whole web.
Camera and microphone are a different switch
People bundle every prompt into one privacy story. They are not the same control. A blocking exception is about whether known ads, analytics, and social trackers from bundled lists may load for that site. Camera and microphone access is a different switch. Sites ask. You allow or deny for that origin. Allowing a page through the blocker does not grant it the camera. Denying the microphone does not restore a blocked ad host. The dedicated permissions page is Per-Site Camera and Microphone Permissions.
HTTPS-Only Mode is a third control. It is on by default. The app asks before falling back to insecure HTTP. That is a connection policy. It does not decide whether a listed tracker may run. It does not hide your IP. Encryption hides contents from some observers on the path. It does not hide the host, and it does not replace a block list. A tracker over HTTPS is still a tracker until a rule matches, or until you except the site.
Intruder Photo, if you enable it in Stealth Suite, is a fourth camera: the lock, not the page. Permission is asked when you turn that feature on, never at the lock screen. It has nothing to do with a blocking exception. Mixing these dialogs is how people think they turned off the network by tapping one control. Keep them named.
Lists still miss names when you never except
Skipping exceptions only means you did not punch a local hole. It does not make the list complete. New trackers appear. Some requests never match a rule. The lists ship in the binary. When we release an app update, the copy you install is the copy you browse with. There is no runtime download of a fresher file. That choice keeps a list server out of the path. It also means the ship date is a freeze date. Something registered after that freeze is a miss until the next release. How the file lives on device is How On-Device Block Lists Work.
Lag is the cost of not phoning home. A blocker that updates every hour is a blocker that can see the app is open. We would rather miss a new analytics host than run a feed that watches you in order to stay current. Even a daily feed would miss names that never make a public list. Private trackers, one-off pixels, and first-party copies do not always have a convenient hostname. iOS content blocking has limits. Treat the feature as coverage of a known set.
Fewer extra requests can also make a page feel lighter. Ads auction. Analytics reports. Social widgets pull. Each extra request is work. Blocking those known extras means fewer third-party requests start. That is a mechanism, not a stopwatch. We do not publish catch rates or millisecond tables. When a needed module matches, the same mechanism is why the page feels broken. The speed-adjacent explanation, without invented numbers, is Why Pages Can Load Faster With Blocking.
Not a VPN, not a global off switch
An exception does not hide your IP. The site you opened still sees the address your network presents. Your carrier or Wi-Fi operator can still see destinations. Allowing listed extras through only means more third-party companies may see the visit too. That is a worse network picture for that site, not a better one. A private browser without a VPN is still a browser. The jobs stay separate in A Private Browser Without a VPN.
An exception is not a global off switch. Other sites keep the lists. Other tabs keep the forgetful session. App Lock with a six-digit passcode and Face ID is free and unrelated. Search suggestions stay off until you ask. None of those controls is rewritten because one checkout needed a host the lists also use for ads. Stealth Suite does not sell a stronger list or a paid exception engine. The blocker is free and already in the binary.
Rated 17+ still applies. This is unrestricted web access. You choose URLs. You are responsible for using the app lawfully. An exception will not make a site appropriate and will not hide you from a network administrator. It will let a broken page try again with more of its requests allowed. That is a real feature. It is not a cloak, and it is not a confession we receive.
A table of two holes
If you are matching the hole to the job:
| What happened | What an exception does | What it does not do |
|---|---|---|
| A needed module never loaded | Allows listed names for that site, locally | Does not phone home. Does not sync |
| You never added an exception | Lists still run on device | Still not 100 percent |
| A page asks for camera or mic | Nothing. Different switch | Not a blocking exception |
| You wanted a hidden IP | Nothing. Not a VPN | Sites and the network still see it |
| You finished the task | Erase still destroys the session | Does not unsay requests already sent |
Use that table when a page looks empty and you are tempted to blame the whole product. Keep blocking on by default. Except the site when you need the module. Erase when the session should die. Do not treat the hole as a score, and do not treat the shield as sealed if you opened it. Private Browser Incognito is iOS only. The lists stay on the device. The exception stays on the device. We stay out of the report.
Frequently asked questions
Can I turn blocking off for one site?
Yes. Per-site exceptions exist when a page needs a blocked resource to function. The exception is a local choice on that device. It does not report to us, and it does not disable tracking protection everywhere else. Finish the task, then erase if you do not want that site's cookies to linger for the rest of the session.
Why does a page break when blocking is on?
A blocker that never breaks a page is a blocker that is not matching much. Video players, comment threads, paywalls, and checkout scripts sometimes live on hosts the lists also use for ads. When the rule matches, that module never loads. That is ordinary list-based blocking, not a bug we hide. Exceptions exist so you can finish anyway.
Does a blocking exception send data to the app maker?
No. The exception lives on that iPhone, in this app. There is no account and no app server for browsing. Block lists ship inside the app and are not downloaded at runtime. Turning an exception on does not phone home. The App Store privacy label is Data Not Collected. We do not receive a report that you allowed a site through.
Is turning blocking off the same as camera or microphone permission?
No. A blocking exception is about whether known ads, analytics, and social trackers from bundled lists may load for that site. Camera and microphone access is a different switch: sites ask, you allow or deny for that origin. Allowing a page through the blocker does not grant it the camera. Denying the microphone does not restore a blocked ad host.
Is tracker blocking 100 percent if I never add exceptions?
No. Tracking protection blocks known names from bundled Disconnect lists that run on the device. New trackers appear. Some requests never match a rule. First-party scripts can look like the site you opened. Skipping exceptions only means you did not punch a local hole. It does not make the list complete. Treat blocking as a reduction of known noise.