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. Private Browser Incognito is rated 17+ for unrestricted web access and is intended for adults.
Two products can both say they block ads and still be different machines. A content blocker inspects requests inside a browser and refuses the ones that match a rule. A DNS filter answers name lookups and can refuse to resolve a host, often for more than one app. The first lives with the page load. The second lives with the resolver. Private Browser Incognito is the first design. It is not the second, and it is not a VPN that happens to mention ads.
Confusion is reasonable. Store listings collapse “blocking” into one word. Settings on iPhone also offer network-level tools that look adjacent. This page names the architecture so you can pick a tool for the job it actually does. We will stay factual about DNS filters. They are a real design with real tradeoffs. They are simply not what this app is. The product-level overview of our lists is On-Device Ad and Tracker Blocking on iPhone.
What a content blocker is doing
You type a URL or follow a link. The browser loads the document from that host. Subresources try to follow: scripts, images, frames, beacons. Content-blocking rules inspect those requests against a list. A match does not go out. A non-match does, using the usual HTTPS path when the site supports it. Matching is mechanical. It is not a person reading the page. It is not a remote proxy rewriting the stream.
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. Opening a tab does not check a list server. There is no second download you opt into, and there is no profile to install so iOS will send lookups somewhere else. The rules are already there, next to the rest of the binary.
That location is a privacy choice. The app has no accounts, no sign-in, and no app server for browsing. The App Store privacy label is Data Not Collected. There is no analytics SDK, no ads in the app, and no third-party SDKs. A list updater would have been a quiet exception. We did not add one. The network the app makes is the pages you visit, a search engine if you search, optional suggestions if you opt in, downloads you start, and StoreKit if you purchase. Block lists are not on that list because they never leave with you. How the file actually lives in the binary is How On-Device Block Lists Work.
What a DNS filter is doing
DNS is how a name becomes an address. A filter in that path can refuse known ad or tracker hosts so the lookup never completes. That can stop a request before a browser even tries to fetch the resource. Because many apps look up names, a system-wide filter can affect more than one process. That breadth is the usual reason people install one. It is also the usual cost: a resolver sits in the path for traffic that is not this browser.
On iPhone, that design often needs a configuration profile, or a local VPN shell, so the system will send lookups to the chosen resolver. Those are real iOS mechanisms. They are how a network-level tool gets into the lookup path. Private Browser Incognito does not require a profile. It does not require a local VPN shell. Its rules apply to this app’s tabs. They do not claim to clean Safari, Mail, or a game’s web view.
A DNS filter can also miss things a content blocker can see, and the reverse is true. A lookup that never happens will not load that host. A request to a host that still resolves, with a path the list does not know, can still go out. Neither design is a census of the advertising industry. Both are list-shaped. Treating them as synonyms hides those shapes.
Not a VPN, and not a list server
A VPN encrypts traffic to a remote hop and, in typical consumer use, changes the IP address sites see. That is a network product. Private Browser Incognito is not one. We do not hide IP addresses. We do not route browsing through our servers. We do not market a proxy. Sites you visit and your network operator can still see your address. On-device blocking only means a matched extra request never started from this process.
Some blockers that people group with DNS filters are actually VPN-shaped ad products: traffic goes through a hop that claims to strip ads. That hop sees destinations. It may assign you a different IP. It is a different trust story from a rule file in an app you already installed. We are not in that category. If you wanted a new IP, you wanted a VPN, and this browser will not pretend to be one.
A remote list server is a third lookalike. Some blockers keep a fresh file in the cloud and pull it on a timer. Freshness is real. So is the telemetry of the pull: the fetcher learns the app is open. We took the freeze instead. Updates arrive as App Store updates to the app that contains the lists. If you never update, you keep the older freeze. That is visible, boring, and honest. The gap that freeze leaves is the subject of Tracker Blocking Is Not Absolute.
Private Browser IncognitoDisconnect lists ship in the app. Nothing to fetch while you browse.
Get the app
Scope: this browser, not the rest of the phone
On-device content blocking in Private Browser Incognito is scoped to this app. A tab in this browser is where the rules run. Mail is Apple’s app. Safari is Apple’s browser. Other apps that load web views are other processes. We do not claim to sit in the middle of those. If you wanted whole-device filtering, you would be choosing a different architecture, with a profile or a resolver in the path, and a different set of honest limits about who sees lookups.
That narrower scope is a feature of the local stance, not a missing toggle. The app already refuses an account, a browsing server, and a runtime list download. Adding a system-wide filter would put a network component under a product that is trying not to be a network product. We would rather say this browser than imply this iPhone. Blocking in one process is still useful. That is not a speed-test claim with numbers, and it is not a promise about the rest of the home screen.
Per-site exceptions exist when a page needs a blocked resource to function. An exception lives on that device, for that app. It does not report to us. It does not disable the lists on every other tab. Finish the task. Erase if you do not want that site’s cookies for the rest of the session. One-tap erase closes every tab and destroys cookies, cache, and site data. The lists themselves are not erased. They are part of the app, not part of the session. Closing a single tab is not erase, and it is not a blocker setting. Those verbs stay separate in Closing Tabs vs Erasing the Session.
What lists catch, and what they do 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 it sits outside, it can pass. There is no fourth bucket called everything a company might learn.
The site you typed is still a party to the visit. It sees your IP address, the usual headers, and whatever you type into its forms. Blocking extra requests is a reduction of known noise. It is not invisibility to the destination. Your network operator still sees that a connection happened. HTTPS-Only Mode is a related default, not a blocker. It encrypts the hop when the site supports it and asks before falling back to HTTP. A tracker over HTTPS is still a tracker until a rule matches.
New hosts appear after a freeze. First-party scripts can look like the site you opened. Fingerprinting can use signals we do not claim to spoof. We do not sell anti-fingerprinting as a product. Rated 17+ still applies: this is a real web browser with unrestricted access. You choose URLs. You are responsible for using the app lawfully.
A compact map of the designs
If you are comparing tools, a table is more useful than the word private printed on both listings.
| Design | Where the decision happens | What else is in the path |
|---|---|---|
| On-device content blocking | Rules inside this app’s binary | Nothing extra. This process only |
| DNS filter | A resolver you install | Lookups for many apps, often a profile or local VPN shell |
| VPN ad product | A remote hop | Your traffic, often a new IP story |
| Runtime list download | A server you contact while browsing | A fetcher that knows the app is open |
Private Browser Incognito occupies the first row. Disconnect categories ship in the app. Rules run on the device at request time. No list download while you browse. Not a DNS filter. Not a VPN. Not 100 percent. Stealth Suite does not change how lists work. The blocker is free and already in the binary. There is no paid stronger list.
Use the lists. When a page breaks, exception, finish, erase. When you are done with the session, destroy it. When someone else might open the app, lock it. None of those switches hides your IP. Together they are a local stance: less extra traffic from this browser, nothing to trust us with, a gap we will not paper over. If you needed whole-device DNS filtering, that is a different product, and it should say so without borrowing our row.
Private Browser IncognitoFree on the App Store. No history, on-device blocking, one-tap erase.
Get the app
Frequently asked questions
Is Private Browser Incognito a DNS filter?
No. It uses on-device content-blocking rules powered by the open Disconnect lists that ship in the app. A DNS filter answers name lookups, often with a configuration profile or a local VPN shell, and can sit in the path for many apps. These rules apply to this browser. They do not require a profile or a local VPN shell.
Do the block lists download while I browse?
No. The lists ship inside the app and run on the device. They are not downloaded at runtime. Opening a tab does not check a list server. An App Store update is how a newer copy of the lists arrives. That freeze keeps a fetcher out of the browsing path.
Does on-device content blocking hide my IP address?
No. A browser is not a VPN and does not hide your IP address. Sites you visit and your network operator can still see it. Content blocking means a matched extra request never started from this app. Page loads still go to the sites you open. We do not route browsing through our servers.
Does this blocker work in Safari and other apps?
No. On-device lists in this browser are content-blocking rules for this app's tabs. They do not claim to clean Safari, Mail, or other processes. A DNS filter is a different design that can affect many apps because it sits on name lookups. We are not that design.
Is tracker blocking in a content blocker 100 percent?
No. Tracking protection blocks known ads, analytics, and social trackers from bundled lists that run on the device. No blocker catches everything. New trackers appear, some requests are not on any list, and per-site exceptions exist when you need a page to work. Treat blocking as a reduction of known noise, not as a guarantee.