HAR to JMX Converter: Turn a Chrome Recording into a JMeter Test Plan

This guide walks through capturing network traffic in Chrome as a HAR file and converting it to Apache JMeter’s JMX format — including a free converter that runs in your browser, so the recording never leaves your machine. That matters more than for most files: a HAR saved with content holds cookies, tokens and response bodies from a real session, which makes an upload converter a poor first choice for it. And a raw conversion is not a finished test — the sections below cover what you still have to fix before the script will actually run.

What is a HAR File?

HAR (HTTP Archive) is a JSON-formatted archive file format for logging web browser interaction with a site. It captures all network requests, responses, headers, cookies, and timing information.

Capturing HAR Files

1. Open Chrome’s Developer Tools (Ctrl + Shift + I)
2. Navigate to the Network tab
3. Browse through the pages you want to capture
4. Right-click in the Network panel
5. Select “Save all as HAR with content”

Capture “with content” if you can. The response bodies are what any tool needs in order to work out which values a later request is echoing back — see correlation below.

Converting to JMX Format

Apache JMeter does not natively support HAR files, so the recording has to be converted.

A straight conversion. Our free HAR to JMX converter takes a HAR and gives you back a JMX — or a k6 or Gatling script — with the recording’s own timings kept as think times. It runs inside your browser tab: the recording is never uploaded, which matters here more than usual, because a HAR captured with content holds every cookie, token and response body from the session you recorded. It is free up to 25 requests, which covers a single user journey.

A conversion that also correlates. None of the above extracts anything — including ours, deliberately: the browser converter replays the recorded values as they were captured, and tells you so on the result. Perf Script Studio reads the HAR and emits a runnable JMeter, k6 or Gatling script, with the dynamic values already extracted (see below), think times taken from the recording’s own timings, and parallel requests grouped as JMeter models them. It is a paid command-line tool, and it exists precisely because of the section that follows.

Other options, and why they are secondary. JMeter’s own Templates > Recording, driven through the HTTP(S) Test Script Recorder, gets you to a similar place without a HAR file at all — if you can re-record the journey through the proxy. Upload-based HAR-to-JMX sites, including BlazeMeter’s converter, are convenient, but the HAR leaves your machine: BlazeMeter’s own documentation lists the converter’s limits and notes that sensitive data in the file may be transmitted. For an authenticated journey, prefer a local path first and decide from there.

Why a HAR is a bad file to upload

A HAR is not a sanitised test asset. Saved with content, it typically holds:

• session cookies and bearer tokens from the browser that recorded it;
• request bodies — forms, JSON, sometimes credentials;
• response bodies that later requests echo, which is the raw material for correlation.

If you would not email that file to a vendor, do not upload it to a converter either. Convert locally first, and sanitise before you share anything with a human or a SaaS.

Why a raw conversion is not yet a test

This is the part most guides skip, and it is where the time actually goes.

A HAR is a record of one session that already happened. Replay it unchanged and every request carries values that were only valid at the moment of capture:

• Session identifiers. The JSESSIONID or sid in the recording belonged to the browser that made it. Replayed, you are sending someone else’s expired session.
• CSRF tokens. Issued per form render. A replayed token is rejected, usually with a 403 that looks like a permissions bug.
• Generated identifiers. Order numbers, cart ids, upload references — all minted by the server during the recording and meaningless on the next run.
• Timestamps and nonces. Anything the server checks for freshness.

Fixing this is correlation: extracting the value from the response that produced it and substituting it into the requests that use it. In JMeter that means a JSON Extractor, Regular Expression Extractor or Boundary Extractor per value, and a ${reference} everywhere the literal appeared — how to find and extract those values is a guide of its own.

The trap is that a script with none of this in place still runs. It returns 200s from the login page and 403s or empty results everywhere after, and under load every virtual user sends the same stale token — which is not a load test of anything.

What else to fix after converting

• Remove what you are not testing. Static assets, analytics beacons and third-party scripts are most of a HAR by request count and rarely part of the thing under test.
• Add a Cookie Manager. Without one JMeter keeps no session at all between requests.
• Check think times. A replay with no pauses is not user behaviour; it is a spike test you did not mean to write.
• Add assertions. A 200 with an error page in the body is a pass until you assert on the content.
• Parameterise the inputs. One recorded username is one user; a CSV Data Set Config is a population.

Using the converted file

Open the resulting JMX in JMeter. You should have a test plan containing the captured HTTP requests, headers, cookies and parameters — a starting point, not a finished script. Work through the list above before you trust a number that comes out of it. If the converter flagged that values are still literal, work the correlation before you scale virtual users — a green run with one recorded session is not evidence.

And if your destination is k6 rather than JMeter, note that the official JMeter-to-k6 converter is archived — plan that leg of the journey deliberately.