k6 Studio won't convert your JMeter test plan

k6 Studio is Grafana’s desktop app for producing k6 scripts without writing them by hand. It is genuinely good at the job it is built for, and it is regularly recommended to people whose actual problem it cannot solve: getting an existing JMeter test plan into k6.

Those are two different jobs. This post separates them, because picking the wrong one costs a week.

What k6 Studio is

A desktop application for macOS, Windows and Linux, open source under AGPL-3.0, at grafana/k6-studio. Version 2.1.0 was released in August 2026 and the repository is actively developed — checked 17 September 2026, alongside 536 stars and 154 open issues, which is the normal shape of a tool people are really using.

It does three things:

• Records a browser session through its own proxy and saves the traffic as a HAR file.
• Generates a k6 script from that recording, with a visual editor for rules — which requests to keep, what to parameterise, where to add checks.
• Validates the result by running it and showing you each request and response, so you can see a script failing before you scale it up.

It also generates browser-based test scripts with interactions and assertions, and the output is designed to run against Grafana Cloud k6 as well as locally.

If you are starting from a journey you can drive in a browser, that is a strong workflow. The debugging view in particular solves the thing that makes new k6 users give up: a script that returns 200 for everything while testing nothing.

What it does not do

k6 Studio does not read a JMeter .jmx file. It records browsers and imports HAR files. There is no JMX import, and nothing in the repository’s roadmap or issues suggests one is planned.

That matters because the tool Grafana did publish for JMeter conversion — jmeter-to-k6 — is archived. The repository now sits in Grafana’s cold-storage organisation, read-only, with its last commit on 7 February 2022. I wrote about that separately, including the four honest options for the JMX-to-k6 leg.

So the two tools do not compose into a migration path. If someone tells you “use k6 Studio” when you have two hundred JMX files, they have answered a different question.

Which one you need

You have	Use
A journey you can re-record in a browser	k6 Studio. Record, generate, validate.
A HAR file already	k6 Studio, or our free browser converter if you want the same HAR to produce JMeter and Gatling too.
A .jmx and no ability to re-record	Neither. See the archived-converter post — a maintained converter, a rewrite, or paying someone.
A .jmx suite and a deadline	A converter that flags what it could not translate, then a human on that list.

The re-recording question is the one that decides it, and it is usually answered by circumstances rather than preference. You can re-record when the application is reachable, the journey is short, and you have credentials for a test account that behaves like the real one. You cannot re-record when the plan encodes a journey through an environment that no longer exists in that form, when it took someone three days to build and nobody remembers the details, or when there are four hundred of them.

Where our tools sit relative to it

Worth being explicit, since this is our blog.

Overlap. For HAR to k6, k6 Studio and our browser converter do the same job. Theirs has a visual rule editor and a validation runner; ours is a web page with no install, converts to JMeter and Gatling from the same file, and runs entirely in the tab — the recording is never uploaded, enforced by a Content-Security-Policy that forbids network calls rather than by a promise. Ours is capped at 25 requests free. If you are committed to k6 and happy to install a desktop app, theirs is the more complete tool for that path, and I would use it.

No overlap. JMeter and Gatling as sources and destinations. k6 Studio is a k6 tool; converting between the three is the thing Perf Script Studio exists for, and the thing Grafana stopped maintaining in 2022.

A note on what neither does. Correlation intent. Both tools can spot that a value in request 7 came from the response to request 3. Neither can tell you which of the dynamic values in a recording matters — whether the session token is the important one or the analytics beacon is noise. That judgement is the migration, and it is the reason a converted script that runs is not yet a test.

The checks worth running on either output

Whatever produced the script, the same three checks catch most of what goes wrong:

1. Run one iteration with one virtual user and read the responses. If the body of the second request after login is the login form, the session never established and you are load testing your cheapest page.
2. Count requests and distinct endpoints against the source. They should match. A silently dropped step is the most common failure in any generated script — including in my own converter, where an unmappable step inside a conditional used to vanish while the block around it was still emitted.
3. Check the think times. Recorders capture real pauses; generators round them. A recording with 200 ms gaps converted to 1 s pauses cuts your arrival rate fivefold with nothing in the report to show for it.

None of that is a criticism of k6 Studio. It is what you do to any script you did not type yourself.