Load testing from a HAR file: a browser recording becomes a test, no HAR to JMX conversion

Albiferro Yazılım ve Sistem Limited Şirketi (Albiferro Software & System Limited Company) · Published 1 November 2026

Detailed documentation →

The shortest way to turn a user flow (sign-in, search, add to cart) into a load test is to do it once in the browser and record it. The browser's developer tools save that recording as a HAR (HTTP Archive) file: a JSON file with every request the page made, its headers, bodies and responses. Converting that file into a JMeter plan (.jmx) first is a common route; in Spitfire that step is not needed: the HAR file is imported directly and becomes a test that replays the flow.

Why replaying a raw recording is not enough

A recording captures one user at one moment. Replaying it as it is with hundreds of VUs misleads because:

• Fixed tokens. The token a sign-in returned, or an order's id, sits in the recording as a fixed value. Every VU sends the same, possibly expired, value; these values have to be taken from the response on every iteration (correlation).
• A single session. A recorded session cookie makes every VU the same user; the server measures a single session.
• Noise. The recording also has images, stylesheets, fonts and CORS preflight requests. These mostly come from a CDN and say nothing about the application's capacity.
• Fixed addresses. The recording carries the production host; running the same flow on staging means changing every request by hand.

Recording the HAR file

1. Open the browser's developer tools and switch to the Network tab.
2. Go through the flow from start to end like a real user; include the sign-in in the recording.
3. Right-click the request list and choose Save all as HAR.

Careful: HAR files can contain passwords, tokens and personal data. Mind the file's content before sharing it. Spitfire does not write the recording itself into the test, only the requests derived from it.

With Spitfire: from HAR to a test

1. Choose the HAR file with Tests → Import API / HAR → From file (up to 50 MB) and click Read.
2. The page says what was left out of the recording: of N requests, X static files and Y CORS preflights were left out. The remaining requests are listed in recording order.
3. Only GET requests are selected by default, so nothing changes on the target. If you add POST, PUT/PATCH or DELETE, those requests repeat on every iteration; before the test is created each group is confirmed separately and the target host is typed. The confirmation goes into the audit log.
4. Type your test environment's address into Base URL, name the test and create it. The editor opens; review the test and save it.

The import converts the recording like this:

• Correlation: values a response returned and a later request sent back (tokens, order ids) are not replayed as constants; they are extracted into variables. The {"token": "eyJ…"} a sign-in returned becomes Authorization: Bearer {{token}} on every later call.
• Think time: the user's pauses between requests become think time.
• Cookies are dropped from the recording; each VU keeps its own cookies.
• A credential that no response in the recording produced (an expired token) is not written into the test; an empty {{authToken}} variable takes its place.
• Headers the browser adds itself (sec-*, cache validators, user agent) are dropped.
• Every origin becomes a variable: the busiest {{base}}, the others {{base2}}… so the same recording can be pointed at a staging host.

// in the recording
POST /api/login        → {"token": "eyJhbGciOi…"}
GET  /api/orders       Authorization: Bearer eyJhbGciOi…

// in the test
POST {{base}}/api/login   → the token is extracted into a variable
GET  {{base}}/api/orders  Authorization: Bearer {{token}}

Once the test exists, pick the load model: a load test at the expected traffic, a stepped stress test to find the limit, or a soak test that runs for hours (load test types). The flow's steps can be changed one by one in the editor, without code (load testing without scripting).

If you already have a .jmx

If you already converted the HAR into a JMeter plan, you can use that plan too: Tests → Open file reads the .jmx file (it is never run), turns it into a Spitfire test and shows a report of what was converted (importing JMeter plans, migration guide).

Frequently asked questions