There are more ways to throttle your Mac's network than you'd expect. Some are built into macOS, some are built into your browser, some are full-featured proxy tools that happen to include throttling, and some are purpose-built for it. They all work, but they're designed for different situations and different kinds of developers.
This guide compares every practical option — what each tool is genuinely best at, where it falls short, and how to pick the right one for the way you actually work. If you've been meaning to test on slow networks more consistently but haven't settled on a tool, this should help you decide.
| Tool | Cost | Scope | Pkt loss | Auto-off |
|---|---|---|---|---|
| Network Link Conditioner | Free | System | ✓ | ✕ |
| pfctl / dnctl | Free | System | ✓ | ✕ |
| Chrome DevTools | Free | One tab | ✕ | ✕ |
| Charles Proxy | $50 | Proxy | ✕ | ✕ |
| Proxyman | $60/yr | Proxy | ✕ | ✕ |
| Network Throttler | $5.99 | System | ✓ | ✓ |
Network Link Conditioner (NLC) is Apple's own tool for simulating degraded network conditions. It's a preference pane that applies bandwidth limits, latency, and packet loss system-wide. It's free and it works.
If you already have it installed and it's part of your workflow, there's no urgent reason to switch. It supports custom profiles, applies conditions at the system level, and it's maintained by Apple.
The friction is in everything around it. Installing NLC means downloading the "Additional Tools for Xcode" package from developer.apple.com, finding the .dmg, locating the preference pane inside it, and installing it into System Settings. Once installed, enabling it means opening System Settings, scrolling to the NLC pane, selecting a profile, and toggling it on. There's no menu bar indicator — nothing visible tells you throttling is active — so it's easy to forget it's running. There's no auto-disable timer, no way to hot-swap between profiles without going back into the settings pane, and no keyboard shortcut.
For occasional use, none of that matters much. For daily use — the kind of habitual testing that actually catches bugs — the overhead adds up. See our NLC setup guide for full installation instructions and a walkthrough of the common issues.
macOS ships with pfctl (packet filter) and dnctl (dummynet) built in. Together, they let you shape network traffic from the terminal — throttling bandwidth, adding latency, and introducing packet loss without installing anything.
This is the most powerful option if you want full control. You can script throttling into CI pipelines, apply conditions to specific ports or IP ranges, and compose rules that none of the GUI tools can match. If you're comfortable writing shell scripts and you want zero dependencies, this is the way.
The tradeoff is usability. The commands are not intuitive — configuring a dummynet pipe with bandwidth limits and packet loss requires multiple commands, all with sudo. There are no named profiles, no way to switch between presets without re-running commands, and no visual indicator that throttling is active. If you forget to flush the rules when you're done, your entire Mac stays throttled until you notice.
For a full walkthrough of the commands, see our guide to throttling network speed on Mac.
Chrome's built-in network throttling is the tool many web developers reach for first, mostly because it's already open. In the Network tab of DevTools, you can select presets like "Slow 3G" or "Fast 3G" to throttle a single browser tab.
For a quick gut-check — does this page feel usable on a slow connection? — it's hard to beat. No setup, no installs, no risk of forgetting to disable it (it only affects the tab, and only while DevTools is open). If all you need is a rough sense of how a page loads under constrained bandwidth, DevTools gets you there in two clicks.
The limitations are significant if you need anything more than that. Throttling only applies to one browser tab, not the whole system — so third-party scripts loaded from CDNs, WebSocket connections, and anything outside that tab aren't affected. There's no packet loss simulation, no DNS delay control, and the presets are coarse. It also doesn't help at all for testing native apps, Electron apps, or anything that isn't running in Chrome.
Chrome DevTools throttling is not a macOS-specific tool, but it's included here because it's often the first thing developers try — and it's worth understanding exactly where its usefulness ends.
Charles is an HTTP proxy and traffic inspector that's been a staple of macOS development for years. It sits between your app and the network, letting you inspect every request and response in detail. It also includes a throttling feature that can simulate bandwidth limits and latency.
The real strength of Charles isn't throttling — it's the combination of throttling and inspection. If you need to see exactly what your app sends and receives while it's running on a slow connection, Charles gives you both in one window. You can throttle the connection, watch a request fail, inspect the response body, check the timing breakdown, and modify the request to test a fix — all without switching tools.
If throttling is your only need, Charles is overkill. It's $50, it runs as a proxy (which means configuring your system or app to route traffic through it), and the proxy layer can interfere with certificate pinning, VPNs, and certain authentication flows. It's also a heavyweight app — the interface is powerful but dense, and there's a learning curve if you're not already familiar with proxy tools.
For developers who live in Charles for API debugging, the throttling feature is a nice bonus. For developers who just want to toggle a slow connection on and off, it's more tool than you need.
Proxyman fills the same role as Charles — HTTP proxy, traffic inspection, throttling — with a more modern, macOS-native interface. It's built in Swift, feels like a native Mac app, and has a cleaner UI for the most common inspection tasks. It also supports per-host throttling, so you can slow down requests to a specific API while leaving everything else at full speed.
Pricing is $60/year or $100 for a lifetime license, which reflects its positioning as a professional tool for developers who do traffic inspection regularly.
The same caveats apply as with Charles: it's a proxy-based tool, so it inherits the same issues with certificate pinning and VPN compatibility. If you're already using Proxyman for API debugging, its throttling features are convenient. If you're not — if you just need to simulate a slow connection — it's a lot of tool and a lot of money for something that should be simple.
Network Throttler is a menu bar app built specifically for one thing: making network throttling fast and frictionless for daily development. It's $5.99 one-time with a 7-day free trial.
It lives in the menu bar, so toggling throttling is a single click without switching apps. It ships with built-in profiles for common conditions — 3G, Edge, DSL, LTE, lossy WiFi — and you can create custom profiles with exact values for download speed, upload speed, latency, packet loss, and DNS delay. An auto-disable timer lets you set throttling to revert after a set duration, so you don't have to remember to turn it off.
It doesn't use a proxy layer. Instead, it uses a privileged helper to apply conditions system-wide through macOS's packet filter — similar to what pfctl/dnctl does, but wrapped in a GUI with profiles and automatic cleanup. The app is 1.7 MB, runs on Apple Silicon and Intel, and requires macOS 14 or later.
Network Throttler doesn't inspect traffic, modify requests, or do anything besides throttling. That's the point — it's not trying to be a Swiss Army knife. If you need traffic inspection, pair it with Charles or Proxyman. If you need scripted rules for CI, use pfctl. But if what you need is the ability to flip on a 3G profile in one click, test your app, and flip it off — this is what it's built for.
The right tool depends on what you're actually trying to do. Here's a shortcut:
Most developers end up using more than one tool. Chrome DevTools for a quick glance, a proxy tool for deep debugging sessions, and a dedicated throttling tool for daily testing. The key is having the right tool for each situation — and actually using it. For a deeper look at building network testing into your regular development process, see the workflow guide.
You might also find this useful: Building a Network Testing Habit: A Workflow Guide for Developers