How to Limit Bandwidth for One App on Mac

Start Throttlr's proxy, select the application that is using the connection, and enable a download cap, an upload cap, or both. The selected app continues transferring data, but only up to the rates you set. Other applications remain unrestricted unless you also place a limit on them or on a broader Internet or Local Network target.

This is useful when a transfer should keep progressing without consuming all available capacity. A cloud backup can continue during a call, a game can update while you work, and a browser download can run in the background without forcing you to disconnect the whole Mac.

A bandwidth cap is different from a priority setting. Throttlr applies an explicit maximum rate to captured traffic; it does not dynamically rank one app above another. It also does not create rules for individual domains, servers, or ports, and it does not add latency or packet loss.

macOS includes networking controls, but its built-in firewall is designed primarily to control incoming connections to applications and services. It is not a per-app bandwidth limiter and does not provide upload and download speed fields for individual apps.

Activity Monitor can help identify network usage, while router quality-of-service settings may prioritize a device or category of traffic. Neither gives the same local workflow as selecting one Mac process and applying separate directional caps. Apple's Network Link Conditioner can create development test profiles, including constrained bandwidth and adverse conditions, but it is intended for network-condition testing rather than routine control of one selected desktop app.

Per-app rate limiting therefore requires a networking tool that can attribute captured flows to an application and enforce a limit. Throttlr does this through Apple's Network Extension framework on macOS 15 or newer. The Network Extension must be approved and the proxy must be running before it can monitor or control new traffic.

Download traffic moves data toward the app: web pages, media, software packages, cloud files, and game assets are common examples. Upload traffic moves data away from it: backups, file synchronization, video sent during a call, and outgoing attachments all use upstream capacity.

Set only the direction causing the problem when you can identify it. Capping a backup's upload leaves its downloads alone, while limiting a large game download does not unnecessarily restrict small outgoing requests. Use both directions when you need a predictable ceiling for the app as a whole.

The live rate is an observation of current traffic, not a promise that an app will continuously reach the cap. Servers, Wi-Fi conditions, protocol overhead, buffering, and the app's own behavior can all produce a lower or uneven rate. Judge the result over an active transfer rather than from a single instant.

There is no universal best number. First observe the app during representative activity, then choose a cap below its sustained rate while leaving enough capacity for the task to make useful progress. Reduce it gradually and watch whether the protected work becomes stable.

When protecting a call, begin with the background uploader rather than the calling app. Upstream saturation can make audio and video unstable even when a speed test reports ample download capacity. For a download-heavy task, limit that task's incoming rate and leave its small requests unrestricted unless they also create a problem.

Avoid treating the full advertised speed of an internet plan as continuously available. Wi-Fi contention, other devices, VPNs, and remote services change the usable capacity. A practical cap should leave headroom under the connection's observed rate, especially when responsiveness matters more than finishing the transfer as quickly as possible.

For repeatable testing, record the exact upload and download values and the scope you controlled. A production troubleshooting limit and a test profile serve different purposes: one protects everyday work, while the other should reproduce a defined condition consistently.

Throttling lets traffic continue under an explicit ceiling. Use it when the transfer is legitimate but too aggressive. Blocking is a hard stop and fits offline testing or a transfer that must not continue. If you need that behavior, the separate blocking guide explains how to stop and restore both traffic directions safely.

Prioritization gives traffic a relative preference when links are busy; an explicit cap gives a selected target a fixed maximum. Throttlr implements caps, not a priority queue. A cap is easier to reason about when you know how much of the connection a background task may consume, but it does not guarantee reserved bandwidth to another app.

Network conditioning is aimed at reproducing an environment, often by combining limited bandwidth with latency, packet loss, or other characteristics. Throttlr does not simulate latency or packet loss. Developers who need those conditions should use an appropriate conditioning tool; the slow-network guide focuses on the narrower tests that can be reproduced with Throttlr's bandwidth controls and blocks.

The app whose window you see is not always the process opening the connection. Launchers, updaters, XPC services, file-provider extensions, login items, and backup agents can own traffic for a familiar product. Throttlr groups helper identifiers with a parent app when it can identify that relationship, while independently signed services may appear as their own rows.

Generate a known transfer and follow the live rate rather than choosing a row from its name alone. If limiting the main app does not change the transfer, look for a helper or service with matching activity. Be cautious with shared macOS services because a rule may affect more than the visible workflow you intended to control.

The direct-download build can inspect running processes for richer background-service metadata. Because of App Store sandbox restrictions, the App Store build asks you to quit an affected application manually before Throttlr reopens it; the direct build can normally perform that quit-and-reopen sequence. Both builds retain the configured traffic controls during the restart.