How to Monitor Wi-Fi Usage Per App on a Mac

You're on hotel Wi-Fi, the connection feels slower than it should, and you have no idea which app is hogging the link. Activity Monitor will tell you bytes-in and bytes-out per process, but it doesn't tell you whether those bytes went over Wi-Fi or ethernet — or which network you were on at the time. To monitor wifi usage per app on Mac, you need to understand how macOS counts traffic per process, how it routes those bytes through interfaces, and how to surface that data without leaving a heavy app running all day.

This guide walks through what "Wi-Fi usage" really means on macOS, the built-in tools you can use today, and how a menu bar monitor turns the same kernel data into something you can glance at while you work.

What "monitor wifi usage per app mac" actually means

macOS doesn't track Wi-Fi separately from ethernet at the application layer. Every app opens sockets, the kernel routes packets through whichever interface (en0, en1, utun0, etc.) is currently the default route, and per-process counters add up bytes regardless of which physical link carried them.

So when people search for how to monitor wifi usage per app on a Mac, they almost always mean one of two things:

1. Per-app traffic while my Mac is on Wi-Fi — i.e., I'm at a cafe, ethernet is unplugged, so all traffic goes over en0. In this case, "per-app traffic" and "per-app Wi-Fi traffic" are the same thing.
2. Per-app traffic specifically routed via the Wi-Fi interface even when other interfaces exist. This matters on a Mac mini with a USB ethernet adapter, or when you're tethered to a phone hotspot.

Both questions reduce to: "show me bytes per process, and tell me which interface they used." Apple ships partial answers in nettop and Activity Monitor. A dedicated tool fills the gap.

How macOS routes traffic between Wi-Fi and ethernet

Open System Settings → Network. You'll see a list of services in priority order: Wi-Fi, USB 10/100/1000 LAN, Thunderbolt Bridge, and so on. The top-most active service wins for new connections, unless an app explicitly binds to a different interface.

A few things follow from that:

• If both ethernet and Wi-Fi are connected, and ethernet is higher in the service order, almost nothing flows over Wi-Fi until you unplug.
• Background apps that opened a connection while you were on Wi-Fi will keep that connection on Wi-Fi until they reconnect. So switching to ethernet doesn't immediately move iCloud sync — the next reconnect does.
• VPN tunnels (utun*) wrap the underlying interface. Bytes appear on utun0 and on the physical interface that carries the tunnel.

You can confirm the current default interface with route get default in Terminal — it'll print interface: en0 (Wi-Fi) or interface: en6 (USB ethernet) or similar.

Built-in tools: nettop and Activity Monitor

Before reaching for anything new, try the tools already on your Mac.

nettop

Open Terminal and run:

nettop -P -m route

-P sums per process (instead of per-connection) and -m route switches to a route-grouped view. You'll see rows like Slack.21341 with bytes_in and bytes_out updating live. Press c to switch modes, q to quit.

Limits: nettop can't pin counters to a single interface inside its default view, and it doesn't fold helper processes. You'll see Slack, Slack Helper, Slack Helper (GPU), and Slack Helper (Renderer) as four separate rows.

Activity Monitor — Network tab

Activity Monitor's Network tab shows total bytes sent and received per process since the process started. It does not show a live rate, doesn't fold helpers, and doesn't separate interfaces. Useful as a sanity check, not as a real-time tool.

Wi-Fi-specific data: wdutil

sudo wdutil info

prints the link layer state — channel, RSSI, PHY mode, BSSID. Combined with per-app counters, this tells you whether slowness is a radio issue or an app issue.

Why a menu bar tool to monitor wifi usage per app on mac wins

Running nettop in a Terminal window all day is not a great workflow. You want a glance, not a session. That's where a menu bar monitor comes in.

ova sits in the macOS menu bar and shows live up/down rates by default. Click it and you get a per-app list with current rate plus a scrubable timeline of historical usage. Helper processes — Slack Helper, Google Chrome Helper, Discord Helper — are folded under their parent app, so you read "Slack" instead of seven helper rows.

When your Mac is connected over Wi-Fi only, that per-app list is your Wi-Fi usage breakdown. When you have multiple interfaces, you can correlate the timeline with which interface was active.

A 5-minute setup to see Wi-Fi usage per app today

Here's a repeatable workflow you can run right now.

1. Confirm Wi-Fi is the active interface. In Terminal: route get default. Look for interface: en0 (or whatever your Wi-Fi shows in System Settings → Network).
2. Install a menu bar monitor. Drop ova into /Applications. It's about 3 MB, signed and notarized, and runs on macOS 14 and up.
3. Open the menu bar list. You'll see a live rate per app. Sort by current rate to find the talker.
4. Scrub the timeline. Click into the historical view to see whether an app spiked five minutes ago, an hour ago, or has been steady all morning.
5. Cross-check with nettop. If a number looks suspicious, run nettop -P -m route and compare. The two should agree closely — they read the same kernel counters.

See ova in action

A glance-able menu bar bandwidth monitor — local, signed, ~3 MB.

Download for macOS

Reading the data: what's normal, what's not

Some baselines from a typical work day on Wi-Fi:

• Slack idle: 5-30 KB/s in steady state, websocket pings plus presence updates. Higher during a huddle or when someone shares a file.
• Chrome with 10 tabs: wildly variable, often 0-200 KB/s idle, spiking to 5+ MB/s when a video plays or a Drive sync kicks off.
• Spotify streaming: ~150-300 KB/s on default quality, ~700 KB/s on lossless.
• Zoom 1080p: 2.5-3.8 Mbps up and down for a one-on-one, more for gallery view.
• iCloud Photos sync after a phone import: can saturate your uplink for minutes.

If you see sustained traffic from an app that has no business being chatty — a screen saver, a wallpaper updater, a calculator — that's a flag worth investigating.

When per-interface accounting actually matters

Most Mac users have one active interface at a time. But there are real cases where you need per-interface granularity:

• You pay per gigabyte on a hotspot. You want to know how much went over the iPhone tether (en4 or similar) versus normal Wi-Fi.
• You're on a corporate VPN. Traffic on utun0 is split-tunnel sensitive — you want to see what apps actually used the tunnel.
• You have a dual-link Mac mini server. Wi-Fi for management, ethernet for the workload, and you need to confirm nothing leaked the wrong way.

The kernel exposes per-interface counters via sysctl net.link.generic and via getifaddrs(3), but mapping them back to processes requires walking PID-to-socket-to-interface bindings. This is exactly what nettop does internally, and what a good menu bar monitor like ova surfaces in a glance-able UI.

Privacy considerations

A network monitor reads metadata — bytes per process, hostnames in some tools, timestamps. That's sensitive. Before installing anything, check three things:

1. Where does the data live? A monitor that ships your bandwidth history to a cloud dashboard is exporting your behavior. Look for "all data on disk" or "100% local" in the description.
2. Is the app signed and notarized? macOS Gatekeeper will tell you on first launch. An unsigned monitor with kernel access is not a thing you want to run.
3. Does it require an account? It shouldn't have to. A local monitor doesn't need login credentials.

ova is local-only, signed and notarized, and never asks for an account. If you decide it's not for you, the 14-day refund is unconditional.

Common questions

Does Little Snitch already do this?

Little Snitch is a firewall — its job is to block or allow connections. It also shows traffic, but the focus is rules, not metrics. ova is a monitor — its job is to show you what's happening, with no blocking layer. They pair well. Run Little Snitch when you want to enforce policy. Run ova when you want a quiet, accurate readout.

What about Wi-Fi usage on iPhone?

Different OS, different APIs. iOS exposes per-app cellular data in Settings → Cellular but does not expose per-app Wi-Fi data to anyone, including third-party apps. There is no equivalent of nettop on iOS. Sorry.

Does ova work on macOS 13 or earlier?

ova requires macOS 14 (Sonoma) or later. Earlier versions are missing some of the per-process networking APIs the app uses for accurate accounting.

Wrapping up

To monitor wifi usage per app on mac, you really stack two questions: per-process accounting plus per-interface awareness. macOS gives you the raw data through nettop and the kernel; Activity Monitor gives you a snapshot; a menu bar monitor turns the same numbers into a live, scrubable view that doesn't require a Terminal window.

If you only do one thing today, install ova, leave it running for an hour while you work, and check the per-app list. The talkers will surprise you — they always do.