How to Track Time Spent on Websites on Mac (Without Manual Logs)

If you bill by the hour and most of your work happens in a browser, this is where your logs break first. Not because you are careless — browser work is fragmented by design. You open a tab, read for two minutes, switch to Slack, switch back to a different tab, follow a link, lose the thread, and by 5pm you cannot remember what was for which client.

This guide explains a reliable method for tracking website time on macOS without resorting to screen recording or manual stopwatches.

Why browser history alone fails

Safari and Chrome both record everything you visit. That data is technically there. So why is it useless for billing?

History records page visits, not active work time. You can open twelve tabs in a research session and only meaningfully use three. History will tell you all twelve were "visited." It will not tell you which was foreground for ten minutes versus which got a glance.

You also cannot reconstruct sessions from history alone. A history line like "10:42am — github.com/client/repo" does not tell you whether that GitHub tab stayed in focus for two minutes or thirty-five.

To make browser time billable, you need three things history does not provide:

• active-window awareness (was this tab actually focused?)
• domain-level grouping (so 40 tabs on github.com/client collapse into one session, not 40 rows)
• session-duration summaries (start, end, duration — the three columns an invoice actually needs)

The macOS-specific question: Accessibility vs Screen Recording

There are two architectural ways to extract URL and tab data from a browser on macOS. Both are legitimate; they have very different privacy properties.

Screen Recording. The tracker captures pixel data and OCRs it (or uses ML) to extract text. This requires the macOS Screen Recording permission, which puts a permanent indicator in the menu bar. It works for any browser but it sees everything on your screen — including content from other apps you switch to.

Accessibility (AX) API. The tracker walks the browser's UI tree to read the tab strip directly. URL, tab title, and the list of other open tabs are all available without ever reading a pixel. Only Accessibility permission is required. Most well-behaved Mac productivity apps (TextExpander, Raycast, BetterTouchTool) use this API.

Both methods are technically "tracking websites." The privacy posture is not the same. If the app you are evaluating asks for Screen Recording, ask why. If the answer is "to extract URLs," you are paying a much higher privacy price than you need to.

The no-timer workflow

Once you have a tool that captures URL and tab context via Accessibility, the workflow is:

1. Capture passively. Active app + browser context, written to a local SQLite database every five seconds. No manual start/stop.
2. Normalize into domain/session records. Adjacent events on the same domain merge into a single session. A 90-second silence starts a new one.
3. Filter noise. Sessions shorter than ten seconds get dropped — alt-tabbing through windows or transient notifications.
4. Validate at end of day. Spend two minutes correcting the few categories the auto-classifier got wrong (figma.com is Design, not Other).
5. Export weekly summaries. One row per session, with start, end, duration, domain, and tab list. Goes straight into your invoicing flow.

This is far more reliable than memory-based reconstruction, and it scales: more clients does not mean more daily friction.

Categorization rule: user control beats hardcoded labels

A fixed "distraction" or "social" label is wrong as often as it is right. YouTube might be deep tutorial work for a developer learning a new framework, and entertainment for someone else on the same team. Twitter might be how a journalist sources stories.

The right model is to ship sensible defaults — slack.com is Communication, github.com is Development — and then let the user override per domain or per session. Avoid tools that make moral judgments hardcoded into the data model.

Weekly review template (15 minutes)

A weekly review only earns its slot if it changes a decision. Use this template:

1. Which 3 domains consumed the most time? Often surprising; often actionable.
2. Which client or project got less time than planned? This is where invoicing gaps hide.
3. How much time was execution vs. communication? If communication is over 30%, look for the meeting that should have been a doc.
4. Where did context switching spike? Days with 50+ session boundaries are usually days with too many calendar events.
5. What single calendar or process change improves next week? One change. Not five.

If the review does not produce one concrete next-week change, you wasted fifteen minutes. Either the data is wrong, or the questions are wrong.

Privacy checklist before choosing a tool

For macOS specifically, prefer tools that:

• request only Accessibility permission, not Screen Recording or Input Monitoring
• store data locally (the path should be documented; if not, treat as a red flag)
• store license keys in the macOS Keychain, not plaintext config files
• offer CSV or JSON export so you are not locked in
• do not require an account to install or use

These are trust features, not marketing extras. A tracker that hits all five is a tracker you can defend in a privacy-conscious team.

The tool I built

For full transparency: DayReplay is the tool I built around exactly this method. Accessibility-only capture, local SQLite, Keychain-backed license, no telemetry. If the workflow above sounds like what you want, the macOS guide has the install steps, and How DayReplay Works and Security & Privacy Details cover the implementation.

If DayReplay is not the right fit, the workflow above stands on its own — apply it to whichever tool you choose.