Does your time tracker see incognito windows? How to check

25 September 2026 · 6 min read

It might. Private browsing controls what the browser keeps after you close the window; it does not stop other software on the same Mac from asking the browser which page is open. Whether your tracker sees an incognito window depends on how it reads the browser and whether it checks the window’s mode first. You do not have to take anyone’s word for it, ours included: the checks below take about ten minutes.

What private browsing hides, and from whom

An Incognito, InPrivate or Private window is a promise about the browser’s own memory. The pages you visit in it are not kept in history, and the cookies and site data it collected are thrown away when you close the private windows. The next person to open the browser on your Mac will not find your trail there.

That is the whole promise. While the window is open, the browser knows which page is in it and will answer questions about that page from other apps that have been allowed to ask. Private browsing is not a shield against software on the same Mac, and it was never designed to be one.

So the useful question is whether a tracker asks the browser, and whether it checks what kind of window it is looking at first.

Three ways an app can learn which site you are on

On a Mac there are three common routes to a browser’s address, and they differ in whether they can tell a private window from a normal one.

Apple Events. This is the mechanism under AppleScript. A browser publishes a scripting dictionary, a list of what other apps may ask it. Chrome, Brave, Edge and Vivaldi share Chromium’s dictionary: windows, each window’s active tab, the tab’s URL and title, and a window property called mode that answers “normal” or “incognito”. An app using this route can tell a private window apart, if it bothers to ask. macOS makes it get your permission once per browser and lists the result in System Settings, Privacy & Security, Automation; Automation permission on a Mac covers what that switch allows. Safari’s dictionary hands over the current tab’s URL but has nothing that marks a window as private.

Accessibility, reading the address bar. An app with the Accessibility permission can read the interface of other apps as text, and a browser’s address bar is part of that interface. A private window’s address bar is as readable as any other. To skip private windows, such an app has to recognize them from wording in the browser’s interface, which differs between browsers and languages, so it is only as reliable as the tool’s matching.

Browser extensions. A tracking extension runs inside the browser and typically sees every page you open there. Chrome keeps extensions out of Incognito windows unless you turn on “Allow in Incognito” for that extension. In Chrome, type chrome://extensions in the address bar, click Details under each extension, and check that switch.

Ask your browser the question a tracker asks

You can put the Chromium question to your own browser from Terminal. It is exactly what a careful tracker asks before reading any address.

1. Open an Incognito window in Chrome and click in it, so it is the Chrome window you used last.
2. Open Terminal (in Applications, Utilities) and run: osascript -e 'tell application "Google Chrome" to get mode of window 1'
3. The first time, macOS asks whether Terminal may control Google Chrome. Allow it for the test.
4. Terminal prints incognito. Click a normal Chrome window, come back to Terminal, run the same line again, and it prints normal.

In Chrome and its relatives, window 1 is the browser’s front window, the one you used most recently, so switching to Terminal does not change the answer. For the others, replace "Google Chrome" with "Brave Browser", "Microsoft Edge" or "Vivaldi".

Use the same check on any private or guest window you rely on. If it answers “incognito”, a tool that checks mode will leave it alone; if it answers “normal”, it will be treated like any other window. When you are done, switch Terminal off again under System Settings, Privacy & Security, Automation.

Test your own tracker with a decoy site

The mode check tells you what a tracker could know. To see what yours actually does, give it something distinctive to find.

1. Use a site you never visit. example.com and example.org are placeholder domains reserved for documentation, so they will not turn up in your record by accident.
2. Open a private window in the browser you want to test, load example.com, and keep that window in front for three minutes. Scroll or click now and then so the tracker does not decide you have stepped away. Some trackers ignore short visits, so do not rush it.
3. Do the same in a normal window with example.org, as a control.
4. Open the tracker’s report, timeline or export and search for “example”.

Read the result this way:

• example.org appears and example.com does not. The tracker itemizes this browser and leaves private windows alone.
• Both appear. It reads private windows.
• Neither appears. It is not itemizing this browser, so the test has told you nothing yet. Check its settings and try again.

Repeat for each browser and each private kind you rely on. Then look under System Settings, Privacy & Security, at Automation and Accessibility, and at each browser’s extensions: that tells you which of the three routes your tracker holds.

One honest limit: a test shows what a tool records and shows back to you. It cannot prove what an app does with something it read and did not display. That is why the route matters: a tool that checks the mode first never has the private address at all.

How Punchcard handles private windows

Out of the box, Punchcard records app names only and asks no browser anything, so a private window is simply time in Chrome, Brave, Edge or whichever browser it is.

If you switch on “Itemize websites” in Settings, Punchcard reads the front tab’s address over Apple Events in Chrome, Brave, Edge and Vivaldi, only while that browser is the app in front and you are not idle, and keeps only the site name. Before it asks for an address, it asks the window’s mode, and it requests the address only when the browser answers “normal”. For any other answer, it never asks. The time stays on the browser’s own line, so the day total does not change.

We tested these private kinds: Chrome Incognito; Brave’s Private window, Private window with Tor and Guest window; Edge InPrivate and Edge’s Guest window; and Vivaldi’s Private window. None of them answered “normal”, and Punchcard never asked any of them for an address. Safari is not read at all, private or not, because its scripting cannot say whether a window is private; why website time tracking skips Safari explains the details. Firefox and Arc are not itemized either.

The limit is the one the mode check showed you: Punchcard goes by the browser’s answer. A window the browser calls “normal” is read like any other window.

To check it yourself, run the decoy test with itemized browsing on, then export a CSV from Punchcard: one row per session (start, end, app, idle, seconds) plus the site. Search it for example.com and you will find nothing; search for example.org and the normal visit is there. The three private minutes are still counted, on the browser’s own line. The site column holds a bare site name, never a full address; what a site name reveals covers why that difference matters.

Questions

Does a private window still count toward my day?

In Punchcard, yes. The time is recorded as the browser, on its own line, and the day total is the same as if you had used a normal window. Only the site is left out.

If a tracker checks mode, is every private window safe from it?

Only the ones the browser reports as “incognito”. The Terminal check above tells you which those are.

Does turning on itemized browsing let Punchcard see Safari’s Private windows?

No. Punchcard does not read Safari at all. Safari time prints as one line whether the window is private or not.