How to inspect HTTPS traffic on macOS in 2026 (a step-by-step guide)

Sooner or later, every developer hits the same wall. Your app sends a request, the server sends something back, and the screen does the wrong thing. You add a log. The log says what you already knew. So you sit there wondering what actually went over the wire — and that is the moment you need to know how to inspect HTTPS traffic on a Mac.

This guide walks through the full workflow on macOS in 2026: why HTTPS is opaque by default, what a man-in-the-middle proxy does to fix that, and the exact steps to capture, decode, and read every request your machine is making. We’ll use Traceptor — a native Mac HTTP/HTTPS debugger — for the screenshots and shortcuts, but the concepts apply to any proxy you pick.

Why HTTPS is hard to inspect

HTTP is plain text. Twenty years ago you could point tcpdumpat an interface and read the requests as they flew by. HTTPS killed that party on purpose. TLS wraps the entire HTTP exchange in an encrypted tunnel that’s negotiated end-to-end between your app and the remote server. To anyone in the middle — a network sniffer, a coffee-shop router, your own MacBook’s packet capture — the payload looks like noise.

That’s great for security and terrible for debugging. You can see the TCP handshake, you can see the SNI hostname, and you can see how many bytes moved. You cannot see the URL path, the headers, the body, the status code, or the response. None of the things you actually wanted.

So how do you monitor HTTPS traffic on macOS without disabling TLS in your app? You become the middle.

The MITM proxy approach

A man-in-the-middle (MITM) proxy is a program that sits between your app and the internet and terminates TLS on both sides. Your app opens an HTTPS connection — but instead of going straight to api.example.com, it goes to the proxy. The proxy presents a certificate it generated on the fly for that hostname, your app validates it, and a normal TLS session begins. On the other side, the proxy opens its own TLS session to the real server. In the middle, the proxy can read and modify everything.

This only works if your machine truststhe certificates the proxy generates. That’s the entire trick: you install the proxy’s root Certificate Authority into your macOS keychain and mark it as trusted for SSL. From then on, certs signed by that root are valid for any hostname, but only on your machine. Anyone else who tries the same trick on your network will be rejected, because they don’t have your root in their keychain.

Step-by-step: inspect HTTPS on macOS with Traceptor

Let’s capture HTTPS on a Mac from scratch. The whole setup takes less than five minutes. If you’re using a different tool the names will change but the steps won’t.

What you’ll actually find

The first time you watch your own app from the outside is humbling. Even small codebases turn out to be doing surprising things. A short, non-exhaustive list of what teams notice in their first session:

• Stale endpoints. Calls to a v1 URL that the backend team deprecated eight months ago, still answered by a sad little compatibility shim.
• Retry storms. A failing request that fires four times in 900 ms because three layers of the stack — the SDK, your wrapper, and the screen that mounted it twice — all believed they owned the retry policy.
• Oversized payloads. A 600 KB JSON response for a screen that shows six fields. Usually the API returns the entire object graph and the client throws 99% of it away.
• Missing headers. An auth token sent to one host but not the next one in the redirect chain. A Cache-Control header you assumed the CDN was setting and it absolutely is not.
• Unencrypted analytics. A third-party SDK quietly posting device IDs over plain HTTP. This one is especially common in older free SDKs.

None of this is exotic. It’s the kind of thing that’s been in your app for months and that nobody noticed because nobody looked. Looking is the whole point.

Safety: keep it sane

Trusting a custom root CA is a real privilege escalation for the tool that owns it. Treat it that way.

Beyond inspection — rewrite responses too

Once you can read HTTPS, the next move is changing it. The two most useful primitives in any proxy are Map Local(point a URL at a file on disk — available under Tools ▸ Map Local or by right-clicking any captured request and choosing Mock Response) and Scripting (run JavaScript on every matching flow, under Tools ▸ Scripting). A Traceptor script looks like this:

js// Inject a Pro entitlement into the /me response, so the
// upgrade screen renders without touching the backend.
async function onResponse(context) {
  const { request, response } = context;
  if (!request.url.endsWith("/v1/me")) return context;

  const body = JSON.parse(response.body);
  body.plan = "pro";
  body.trial_ends_at = null;
  response.body = JSON.stringify(body);
  return context;
}

Five lines, no backend changes, no feature flag, no deploy. Same trick works for empty states, error states, paid-tier UI, and the once-every-three-months bug that QA can reproduce and you cannot. Inspection tells you what’s happening; rewrite lets you ask what if.

Wrapping up

Inspecting HTTPS traffic on macOS used to be a half-day yak shave. In 2026 it’s a five-minute setup and a permanent superpower. Install a proxy, trust the root on your own machine, point your apps at it, and the network stops being a black box.

Free download. Premium one-time at $29.99, with one year of updates included (50% off this week with code WELCOME). If the first session pays for itself — and it usually does — you’ll wonder how you debugged anything before.