Low Data Mode on Mac: What It Actually Does (And What It Doesn't)

Low Data Mode on a Mac tells macOS and the apps running on it to reduce network usage on one specific connection. When it is switched on, macOS pauses automatic software updates and background App Store downloads, iCloud Photos stops syncing, iCloud Drive and backup activity backs off, Apple's background services go quiet, and video calls such as FaceTime can drop to a lower bitrate. It is configured per network rather than system-wide, so your Mac can treat an iPhone hotspot as expensive while continuing to treat home Wi-Fi as unlimited.

It is worth being precise about the category this feature belongs to. Low Data Mode is not a throttle, a bandwidth limiter, a firewall or a data meter. It does not cap anything, it does not count anything, and it will never tell you that you are approaching a limit, because it has no concept of a limit. It is a single boolean attached to a network, and its entire job is to shift deferrable work to a later, cheaper connection.

That framing matters because it explains both the strengths and the weaknesses. The strengths are that it is instant, free, requires no third-party software and has no performance cost. Apple's own services are the largest source of unexpected background traffic on a typical Mac, and Low Data Mode addresses them directly and reliably. A deferred macOS update alone can be several gigabytes that never leave your data allowance.

The weakness follows from the same design. Because the mechanism is a flag rather than a filter, everything downstream of that flag is voluntary. We will get to why that matters in section three, but keep it in mind while reading what the mode changes: every item on the list is something Apple chose to make responsive to the flag, in Apple's own code.

For Wi-Fi, open System Settings, select Wi-Fi in the sidebar, click the Details button next to the network you are connected to, and enable Low Data Mode in the panel that appears. On older releases running System Preferences, the equivalent path is Network, then Wi-Fi, then Advanced or Details depending on version. The setting arrived on the Mac with macOS Monterey, having existed on iOS since iOS 13.

The important detail is that the toggle belongs to the network, not to the Mac. macOS stores it against that specific SSID and remembers it, so enabling Low Data Mode on your phone's hotspot leaves your office and home networks untouched. The trade-off is that you generally need to be connected to a network, or have it saved in your known networks list, in order to configure it. If you travel and join a new hotspot each time, you have to remember to set the toggle again on each new SSID.

A personal hotspot from an iPhone appears to macOS as an ordinary Wi-Fi network, so it is configured in exactly the same place. If you tether over a cable instead, look under System Settings, then Network, then the iPhone USB interface, where a comparable option is exposed. Wired Ethernet typically does not offer the setting at all, on the reasonable assumption that a fixed line is not metered.

There is no visual confirmation once it is on. No badge, no menu bar item, no notification. The only way to check is to return to the same details panel and look at the toggle. This is arguably the feature's biggest usability problem: a setting that is invisible after you leave the settings window is a setting people forget they enabled, and then forget to disable when they are back on a fast connection wondering why their photo library has stopped updating.

One last point of confusion worth clearing up. Low Data Mode on your iPhone and Low Data Mode on your Mac are entirely separate settings on separate devices. Enabling it on the phone that is providing the hotspot restrains the phone's own traffic. It does nothing whatsoever to restrain the Mac connected to it.

The largest and most reliable effect is on system updates. With Low Data Mode active, macOS will not download system updates in the background, and the App Store defers automatic app updates and background downloads. On a Mac that has been offline for a few weeks, this is usually the single biggest saving available, because a macOS update or a handful of large app updates dwarfs everything else you are likely to do on a hotspot.

iCloud is the second major area. iCloud Photos pauses syncing, which means new shots taken on your phone will not stream down to the Mac and edits made on the Mac will queue rather than upload. iCloud Drive defers non-urgent sync, and backup-related activity backs off. This is genuinely useful behaviour and also the one most likely to surprise people, since a paused sync looks identical to a broken sync. If a colleague says a file is not showing up, check whether the Mac is sitting on a Low Data Mode network before debugging anything else.

Apple's other background services follow the same pattern. Continuity-adjacent features and the various periodic tasks Apple runs on your behalf reduce their activity, Safari trims some speculative preloading, and FaceTime will accept a lower video bitrate rather than saturating a weak connection. Third-party apps built on Apple frameworks may see reduced background scheduling as a side effect, because the system is less willing to wake them for opportunistic network work.

It is equally important to be clear about what does not change. Low Data Mode never interferes with a request you make yourself. Load a page and it loads at full weight. Start a download and it downloads. Open a streaming app and it streams at whatever quality that app decided on. Nothing is compressed, nothing is proxied, and no image is downscaled on the way to you. The mode only touches work the system would have done on its own initiative.

And because there is no accounting layer, you get no feedback about the result. Low Data Mode cannot tell you it saved you two gigabytes, because it never measured anything. It made a set of decisions differently and moved on. For a lot of people that is entirely fine. For anyone actually working against a data allowance, the absence of numbers is the point where the built-in feature runs out of road.

Underneath the toggle, Low Data Mode is an advisory flag. macOS marks the network path as constrained, and exposes that to applications through the Network framework: a path reports isConstrained, connections can be configured through NWParameters to refuse constrained paths, and URLSession offers a per-request switch so a developer can declare that a particular transfer should not run on an expensive network. macOS sets the flag honestly and consistently. What it does not do is police the socket.

The consequence is direct. An application that never reads the flag is completely unaffected by it. There is no kernel-level gate, no traffic shaping, no enforcement layer that intercepts a request from an app that did not opt in. If a developer never wrote the three lines of code that check whether the path is constrained, their software behaves on your metered hotspot exactly as it behaves on gigabit fibre.

In practice that covers a lot of the software people actually run. A browser like Chrome, a sync client like Dropbox, Docker pulling a multi-gigabyte image layer, a game launcher applying a patch, a third-party backup agent starting its scheduled run, an Electron app checking for updates on launch. None of them are obliged to look at the flag, several of them do not, and none of them will tell you either way. Apple's services honour Low Data Mode because Apple wrote them to. Everyone else is on the honour system.

This is a defensible design choice rather than negligence. The application is the only party that knows which of its transfers are deferrable and which are essential, and a system that silently blocked traffic would break software in ways that are hard to diagnose. Cooperative signalling produces better behaviour than blunt blocking when everybody cooperates.

The problem is what happens when they do not. The guarantee is distributed across every developer whose code runs on your machine, you are trusting each of them independently, and you have no way to audit the result. The failure mode is also silent: nothing errors, nothing prompts, nothing appears in a log you would ever look at. You find out when your carrier sends the message about your allowance. This is precisely the gap that per-app enforcement fills, and it is the reason tools like NetMute operate at the network layer rather than by asking nicely.

The alternative approach is to stop asking applications to behave and start deciding for them. NetMute is a per-app firewall and traffic monitor for macOS that enforces at the network layer, which means an application's cooperation is not required and its opinion is not consulted. If a rule says an app does not get the network, it does not get the network, whether or not its developer has ever heard of the constrained path API.

That makes a few things possible that Low Data Mode structurally cannot do. You can set daily or monthly data caps per application as well as a global cap across the whole Mac, get a notification when an app crosses a threshold you chose, and have it blocked automatically when it reaches one hundred percent of its limit. Limits are stored per network profile, so an app can have a tight cap on your hotspot and no cap at all at home, and profiles switch automatically based on the Wi-Fi SSID you join. Hotspot protection handles the awkward captive-portal case, where a network needs to be reachable enough to log in but not open enough to let every background process loose.

The day-to-day side is a real-time per-app traffic monitor showing exactly which process is transferring what, with one-click blocking and self-expiring temporary rules for when you want to silence something for the next hour rather than forever. It answers the question Low Data Mode leaves unanswered: not whether apps were asked to be careful, but how much each one actually sent.

The fair conclusion is that these two things are complementary rather than competing. Turn Low Data Mode on. It costs nothing, it works well for the traffic Apple controls, and Apple's own services are a genuinely large share of background usage. Then add enforcement underneath it for the software that never agreed to the arrangement, so that your data allowance depends on a rule you set rather than on a decision some developer made about their update checker three years ago.