Capturing HTTP Traffic That Isn't in a Browser Tab

If the traffic you care about happens in a browser tab, Chrome DevTools is the right tool and it is already installed — capturing a HAR from DevTools and converting it covers that path end to end.

Everything below is for the traffic DevTools cannot see. Four tools get mentioned and three of them are free, so the order here is by what the job needs rather than by price: Fiddler Everywhere, mitmproxy, JMeter’s own recorder, and — for a different question entirely — Wireshark and tcpdump.

When DevTools Is Not Enough

DevTools is scoped to a browser tab. It cannot show you:

• A mobile app’s API calls. The most common reason to reach for a proxy at all
• A desktop client — an installed application talking to a backend
• A service or script — anything calling an API without a browser involved
• Traffic from another machine on the same network

The answer to all four is an intercepting proxy: something that sits between the client and the network, terminates TLS with a root certificate you install yourself, and reads the decrypted traffic on the way through. Fiddler Everywhere is one; the next three sections cover it, and then the free alternatives that work the same way.

Installing It

Fiddler Everywhere is cross-platform, and it is a commercial product — at the time of writing Telerik offer a 10-day trial and it is a paid licence after that. That is a change from the free beta this post originally covered.

Installation instructions live in Telerik’s own documentation, which stays current in a way a copied set of steps here will not. The version-specific commands this post used to carry had rotted by the time anyone read them.

Capturing

Capture is on by default once the proxy is running, and the interface splits three ways:

• Left panel — the captured traffic as it arrives
• Right panel — the selected request and its response
• Bottom bar — the Capture toggle, for when you want to stop the noise while you set up

For a mobile device, point the device’s network settings at the machine running Fiddler and install the certificate it serves. The device’s traffic then appears alongside everything else.

The Composer tab is the other half of the tool: build a request by hand, send it, read the response. It is the fastest way to establish what an API expects before you script anything against it.

GET http://www.example.com HTTP/1.1
User-Agent: Fiddler

Exporting a HAR

A capture is only useful outside Fiddler if you can get it out. Fiddler exports the sessions it has recorded as HAR (Export > All sessions > HAR v1.2), which is the format every other tool reads.

The Free Alternative: mitmproxy

If a licence is the sticking point, mitmproxy does the same job and is free and open source. It is an intercepting HTTPS proxy with the same model — route the client through it, install its certificate, read the decrypted traffic — and it writes HAR directly, so the rest of this post applies unchanged. It runs headless (mitmdump), which makes it the better option on a build server; Fiddler’s advantage is the interface, not the capability.

JMeter’s Own Recorder

JMeter ships with a proxy of its own — the HTTP(S) Test Script Recorder — and if JMeter is your target tool it is the shortest path there, because it writes samplers straight into a test plan and skips the HAR entirely.

Start from File > Templates > Recording, which builds a plan with the recorder and a Recording Controller already wired up. It listens on port 8888 by default; point your client at it and the captured requests land under the controller.

Two things catch people out:

• The certificate expires in seven days. JMeter generates ApacheJMeterTemporaryRootCA.crt in its bin directory, and proxy.cert.validity defaults to 7. Recording that worked last week failing this week is almost always this
• Record everything and you get everything — analytics, fonts, third-party beacons. Set the include and exclude patterns on the Requests Filtering tab before you record, not after

It has real limits. It only writes JMeter, so a capture recorded this way cannot become a k6 or Gatling script without converting it afterwards; it needs the JMeter GUI running, which rules it out on a headless box; and it records dynamic values exactly as captured, same as everything else here.

Which to use: if you want JMeter and you are happy in the GUI, use JMeter’s recorder — it is free and it is one step. Capture to HAR instead when you want more than one tool out of a single recording, when the person who captured the traffic is not the person writing the test, or when there is no GUI available.

A Note on Wireshark and tcpdump

Both are excellent and neither is a substitute here, because they work a layer below. Wireshark and tcpdump capture packets; Fiddler and mitmproxy capture HTTP sessions by acting as the endpoint that terminates TLS.

That distinction decides what you can do with the result:

• They cannot give you a HAR. No packet capture exports one, because a HAR is a record of request/response pairs, not frames
• HTTPS is opaque to them. Without the session keys — via SSLKEYLOGFILE, which the client has to cooperate in producing — you are looking at encrypted bytes. Since practically all traffic is TLS now, that is most captures

Where they earn their place is the question a proxy cannot answer: retransmits, resets, window sizes, DNS delays, TLS handshake failures, and whether the latency you are seeing is the application or the network beneath it. That is a genuinely useful skill for performance work — it is just a different investigation from building a load test.

From a Capture to a Load Test

A HAR from a mobile app is a particularly good starting point for a performance test, because the request sequence is one you cannot easily reconstruct by reading code.

Our free converter takes that HAR and gives you back a JMeter, k6 or Gatling script, with the recording’s own timings kept as think times. It runs inside your browser tab — the HAR is never uploaded — and is free up to 25 requests, enough for a single user journey.

What it will not do is correlate. The converter replays the values exactly as they were captured, so session IDs and tokens in the output are the ones from your recording and will be stale on the next run; it flags them on the result rather than pretending otherwise. Fixing that is correlation, and it is the difference between a script that runs once and a test.

Before You Share a Capture

A Fiddler capture is more sensitive than a browser HAR, not less. It holds every cookie, bearer token, and response body from every client you were proxying — and if you were capturing a mobile app, that includes whatever the app sends on launch without asking you.

Before a capture goes to a colleague, a vendor or a ticket, run it through the free scanner: it reports where the credentials and personal data are, in your browser, without uploading anything.

Conclusion

Pick by the job, not the brand:

• Browser journey — Chrome DevTools. Free, installed, and it gets you all the way there
• JMeter is the target and you want one step — JMeter’s own recorder
• Headless, scripted, or you would rather not pay — mitmproxy
• You want the interface, and the licence is not the obstacle — Fiddler Everywhere
• The question is about the network, not the requests — Wireshark or tcpdump, and a different afternoon

Whichever captures it, the recording is the easy part. Making it replay as a test is correlation, and that is where the afternoons actually go.