Key takeaways
- Each virtual user needs its own inputs. Without them, a thousand threads log in as the same account and hit the same cached product page.
- Prepare the file before the run, with at least as many rows as the test will consume.
- Sharing mode and end-of-file settings decide which thread gets which row, so set them on purpose.
- For field-by-field detail of the element, see the CSV Data Set Config guide. This post covers how to use CSV data across a whole test.
CSV data in JMeter means a file of rows (usernames, product IDs, search terms) that a CSV Data Set Config element feeds into variables, one row per thread per iteration, so that every virtual user sends different values. It is the standard way to parameterise a JMeter test, and the one that scales to large data sets.
What should you put in a CSV file for a load test?
Put in anything that real users would vary: login credentials, search terms, product or article IDs, postcodes, order quantities. A good test file mirrors production traffic. If 80 percent of real searches hit a short list of popular terms, repeat those terms in the file in the same proportion rather than listing each term once.
A plain file with a header line is easiest to maintain:
username,password,productId
loadtest01,Secret-01,1042
loadtest02,Secret-02,2210
loadtest03,Secret-03,1042Leave Variable Names empty in the element and JMeter reads the first line as the column names. Reference the columns as ${username}, ${password} and ${productId} in samplers, headers or assertions.
How do you prepare CSV test data?
The JMeter manual is direct about this: generating unique random values at run time costs CPU and memory, so create the data in advance of the test. A few habits help:
- Generate the file with a script or a spreadsheet export, not by hand, and keep the generator next to the test plan so you can rebuild it.
- Count the rows you need. If the element should not wrap around, the file needs at least threads multiplied by iterations per thread. A 50-thread test that loops 20 times consumes 1,000 rows.
- Use dedicated test accounts, never real customer data, and never commit real passwords with the plan.
- Match the encoding. Set File Encoding to the encoding the file was saved in (UTF-8 is a safe default) if names contain accented characters.
- Quote values that contain the delimiter. Enable Allow quoted data and write
"Smith, Jane"as one value; a doubled double-quote inside a quoted field stands for one literal quote.
How do you give every thread its own row?
By default the file is opened once and shared: each thread takes the next unused line, and which thread gets which line depends on the order the threads execute, so it can differ between iterations. Lines are read at the start of each test iteration.
If you need a different arrangement, the Sharing mode setting decides it:
| Sharing mode | What it does |
|---|---|
| All threads (default) | One file pointer for every thread in the test plan |
| Current thread group | The file is opened once for each thread group that contains the element |
| Current thread | The file is opened separately for each thread |
| Identifier | Threads sharing the same identifier share one file, even across thread groups |
For one fixed list of data per virtual user, the manual’s pattern is a set of files, one per thread (test1.csv, test2.csv and so on), with the filename test${__threadNum}.csv and the sharing mode set to Current thread. That suits cases where each user owns their own data, such as a personal cart or inbox.
What happens when the CSV file runs out of rows?
That is set by Recycle on EOF? (default true) and Stop thread on EOF? (default false):
- Recycle true: reading starts again from the first line. Rows repeat, so two threads can end up using the same account.
- Recycle false, Stop thread false: every variable is set to
<EOF>once the file is exhausted, and requests carry that literal text. A run that suddenly fills with failed logins midway often points here. The string can be changed with the propertycsvdataset.eofstring. - Recycle false, Stop thread true: the thread ends. That is what you want when each row must be used once, for example a one-time voucher code.
Check the number of rows against the load profile before a long run. A ramp-up period spreads the first reads over time, but the total rows consumed still depends on threads and iterations.
How do you parameterise logins with CSV data?
Put the credentials in the file and reference them in the login sampler, then keep the session per thread: JMeter’s HTTP Cookie Manager stores cookies per thread, so each virtual user keeps its own session as long as you do not share accounts between threads.
If the application locks a user out of a second concurrent session, give each thread a unique row: Recycle false, Stop thread true, and enough rows for every thread. If the login returns a token, extract it with a Regular Expression or JSON Extractor and send it in later requests; the CSV login credentials and token extraction walk-through shows that flow end to end. For the broader picture of parameters, see parameterization in JMeter.
How do you pick random rows from a CSV file?
The built-in element reads lines in order. For random selection there are two common routes. One is to shuffle the file when you generate it, which costs nothing at run time. The other is the Random CSV Data Set Config, a separate plugin from the BlazeMeter plugin set (github.com/Blazemeter/jmeter-bzm-plugins). Its documentation lists a Random order option, a Rewind on end of list option, and Independent list per thread, which gives each thread its own randomised copy of the values. It reads the whole file when the test starts, so a very large file delays startup and uses a lot of memory.
How do you run a test with CSV data in the cloud?
Run a short local test first, then upload the plan and the CSV file together. On LoadFocus JMeter load testing, CSV data files are uploaded with the test plan, and you set virtual users, duration and ramp-up per run without editing the script (loadfocus.com/jmeter-load-testing, checked October 2026). Keep the filename in the element as a bare name such as users.csv; a relative name resolves against the test plan’s own folder, and the manual notes that absolute paths are unlikely to work on a remote server.
In a distributed run the manual says the file must exist on each server, so each generator reads its own copy and two generators can use the same rows. If accounts must be unique, split the data per generator or use accounts that tolerate parallel sessions, and check on a small run first.
Frequently Asked Questions
How do I use a CSV file in JMeter?
Add a CSV Data Set Config to the thread group, enter the file name, then list the variable names or leave them empty so JMeter reads the header line. Use ${columnName} in samplers. Each thread reads a new line at the start of every iteration.
Why do all my threads use the same value?
Check the sharing mode first, then the row count. If the file has fewer rows than the test consumes and Recycle on EOF is true, rows repeat. Add a View Results Tree listener on a short run and read which value each request carried.
How do I stop JMeter from reusing CSV rows?
Set Recycle on EOF to false and Stop thread on EOF to true, and provide enough rows for the whole run. With Stop thread false, the variables become <EOF> instead, which will fail requests.
Can each thread use its own CSV file?
Yes. Name the files with the thread number, for example test1.csv, test2.csv, set the filename to test${__threadNum}.csv and the sharing mode to Current thread.
How do I save JMeter results to a CSV file?
That is a different task: results are written by the listener or the -l option, covered in saving JMeter results to a CSV or XML file.
Sources
- Apache JMeter user manual, CSV Data Set Config (read October 2026)
- BlazeMeter jmeter-bzm-plugins, Random CSV Data Set Config (read October 2026)
- loadfocus.com/jmeter-load-testing (checked October 2026)
