Generating Dynamic IDs in JMeter for Enhanced Test Automation

To generate a unique ID in JMeter, use ${__UUID()}. It returns a random version 4 UUID such as c69e0dd1-ac6b-4f2b-8d59-5d4e8743eecd, a new one on every call, and works in any field: path, parameters, body data or headers. For a readable sequence (1, 2, 3 or ORDER_000042), use a Counter config element. For anything custom, use a JSR223 PreProcessor with Groovy. Everything below was checked against JMeter 5.6.3.

Key takeaways

• ${__UUID()} is the simplest unique ID in JMeter. It takes no arguments and cannot store its value, so save it in a variable when several requests need the same ID.
• A Counter gives predictable, sequential IDs. Set Increment to 1: it defaults to 0, which means the value never changes.
• ${__time()}, ${__Random()} and ${__RandomString()} are not unique. Two threads in the same millisecond, or two equal random draws, produce the same value.
• Unique data per virtual user matters: requests that all hit the same record mostly measure a cache.

Which JMeter function to use for a unique ID

Use __UUID when the ID only has to be unique, a Counter when it should also be readable or sequential, and Groovy when the format is fixed by the application, such as a prefix plus a number. Random functions are for test data that should vary, not for keys that must never repeat.

How to generate a UUID in JMeter with __UUID

Write ${__UUID()} where the ID is needed. JMeter evaluates it each time the field is used, so every request, thread and iteration gets a new value. The function has no arguments, so it cannot store its result for a later request; when the same ID must appear in two requests, save it in a variable first, as shown below.

POST /api/orders
{"orderId": "${__UUID()}", "quantity": 1}

A version 4 UUID carries 122 random bits, so the chance of two matching in a load test is negligible. That makes it the right default for request IDs, idempotency keys, correlation headers and new records.

How to reuse the same UUID in several requests

Generate it once in a JSR223 PreProcessor (or with the __groovy function, which can store its result) and reference the variable everywhere else. A PreProcessor runs before the sampler it is attached to, so attach it to the first request that needs the ID.

1. Right click the first sampler that needs the ID and choose Add > Pre Processors > JSR223 PreProcessor.
2. Leave Language on groovy (the default since JMeter 3.1) and keep Cache compiled script if available ticked.
3. Enter the script:

vars.put("orderId", UUID.randomUUID().toString())

Later requests in the same thread can use ${orderId}. The one-line alternative, without a PreProcessor, is ${__groovy(UUID.randomUUID().toString(),orderId)} in the first request: it returns the UUID and also stores it in orderId. JMeter variables belong to a thread, so each virtual user keeps its own value.

How to create sequential IDs with the JMeter Counter

The Counter config element produces a number that goes up by a fixed step on each iteration, with an optional format. Use it when IDs must be readable or ordered, for example ORDER_000001, ORDER_000002.

1. Right click the Thread Group and choose Add > Config Element > Counter.
2. Set Start (for example 1), Increment (1) and, if you want the sequence to wrap, Maximum. Increment defaults to 0, and a counter with no increment returns the start value every time.
3. Optional: Number format takes a Java DecimalFormat pattern. ORDER_000000 produces ORDER_000001.
4. Set Exported Variable Name, for example orderNo, and reference it as ${orderNo}.
5. Leave Track counter independently for each user unticked for one shared sequence: user 1 gets 1, user 2 gets 2. Tick it to give every user its own count.

The __counter function is the inline version: ${__counter(FALSE,seq)} is a global counter that starts at 1 and adds 1 each time it is evaluated, and TRUE keeps a separate count per user. Its maximum is 2,147,483,647, and each __counter in the plan keeps its own count.

Both counters live inside one JMeter process. In a distributed test, every load generator starts its own sequence, so two engines produce the same numbers. Add something engine-specific, such as a prefix passed with -Jengine=a, or use a UUID.

Why __time and __Random do not give unique IDs

They are fine for varied test data and wrong for keys that must never repeat. ${__time()} returns the current time in milliseconds, and dozens of threads can read the same millisecond. Random functions repeat sooner than intuition suggests: with 1,000 draws from 1 to 1,000,000, the chance that at least two match is about 39%.

The syntax, for when variety is what you need:

• ${__time(YMDHMS)} returns a timestamp like 20261023-091500. Since JMeter 5.5 the format is a Java DateTimeFormatter pattern, so ${__time(yyyyMMdd-HHmmss)} works too. Good for file names and run labels.
• ${__Random(1,999999,rnd)} returns a number between 1 and 999,999 inclusive and stores it in rnd.
• ${__RandomString(10,abcdef0123456789,rs)} returns 10 characters drawn from that set and stores them in rs. Without the second argument it uses any characters, readable or not.
• The Random Variable config element (Add > Config Element > Random Variable) sets a variable at the start of each iteration from a Minimum Value, Maximum Value and an Output Format such as USER_000000. Per Thread(User) ? gives each thread its own random generator.

How to build a custom ID format with Groovy

When the application expects a specific shape, build it in a JSR223 PreProcessor. Read variables with vars.get() and never put ${...} inside the script, so Groovy can compile it once and cache it.

import org.apache.commons.lang3.RandomStringUtils

// 10 random letters and digits (commons-lang3 ships with JMeter)
vars.put("token", RandomStringUtils.randomAlphanumeric(10))

// Readable and unique within one JMeter instance: thread number plus iteration
vars.put("orderRef", "ORD-" + ctx.getThreadNum() + "-" + vars.getIteration())

// Prefix plus a UUID when it must be unique across load generators too
vars.put("customerId", "CUST-" + UUID.randomUUID().toString())

ctx.getThreadNum() starts at 0 and is only unique within its Thread Group, so add the group name (ctx.getThreadGroup().getName()) if several groups create orders. JSR223 code costs CPU on the load generator; for simple IDs the built-in functions are cheaper. See which language JMeter uses for scripting for why Groovy replaced BeanShell.

Where to put ID generation in a test plan

Generate the ID as close as possible to the request that first sends it. Functions in a sampler’s fields run when that sampler runs; a PreProcessor runs just before its parent sampler; config elements such as the Counter and Random Variable update once per iteration. The execution order of JMeter elements decides which value a request sees.

Do not put ${__UUID()} or ${__Random()} in a User Defined Variables element. User Defined Variables are evaluated once when the test starts, so every thread would share a single value. When the IDs must exist in the system under test already, such as customer numbers, read them from a file instead with a CSV Data Set Config, or see the wider guide to parameterization in JMeter.

Random variables in LoadFocus tests

The LoadFocus load test builder creates tests from URLs without a script, and each request has a Random Variables option. You give the variable a name, an output format and a minimum and maximum value, then reference it as ${name} in the test’s requests, for example in the URL or the POST body. If you already have a JMeter plan that builds IDs with the functions or Groovy above, LoadFocus runs the .jmx as it is, JSR223 elements included.

Random Variables in the LoadFocus load test builder.

Frequently Asked Questions

How do I generate a UUID in JMeter?

Use the built-in function ${__UUID()} in any field of a sampler, for example in body data or a header. It returns a random version 4 UUID on every call. To use the same UUID in several requests, store it once with a JSR223 PreProcessor (vars.put("id", UUID.randomUUID().toString())) and reference ${id}.

Is __Random unique in JMeter?

No. __Random returns a random number in the range you give, and numbers repeat. With 1,000 draws from a range of one million, the chance of at least one duplicate is about 39%. Use __UUID or a Counter when duplicates would break the test.

What is the difference between the Counter element and the __counter function?

Both count. The Counter config element has a start, increment, maximum and number format and updates once per iteration. The __counter function always starts at 1, adds 1 each time it is evaluated and has no format option. Use the element for formatted sequences and the function for a quick inline number.

Why does unique data per virtual user matter in a load test?

Because reusing the same record means every virtual user hits the same cache entry or the same row. The results look fast and say little about how the system behaves with real, varied traffic. Some APIs also reject duplicate keys, which turns a performance test into a wall of errors.

Do these IDs stay unique in a distributed JMeter test?

UUIDs do. Counters, __counter and thread numbers restart on every load generator, so two engines produce the same values. Combine them with something that differs per engine, such as a property passed with -J, or switch to UUIDs.

Sources

• Apache JMeter user manual, Functions and Variables (__UUID, __Random, __RandomString, __time and its DateTimeFormatter change in 5.5, __counter limits, __groovy), read 23 October 2026.
• Apache JMeter component reference, Counter and Random Variable (fields, defaults, per-user options), read 23 October 2026.
• Apache JMeter component reference, JSR223 PreProcessor and Best Practices (Groovy, compiled script caching), read 23 October 2026.
• Apache JMeter, third-party library versions in the 5.6.3 source (commons-lang3 3.14.0, Groovy 3.0.20), read 23 October 2026.
• IETF, RFC 9562: Universally Unique IDentifiers (version 4 UUIDs, 122 random bits), read 23 October 2026.

Related reading

• JMeter Load Testing Tutorial: Local, Distributed, Cloud
• How Does JMeter Work? Threads, Samplers and Results
• Correlation in JMeter: Extractors, Steps and Fixes

Run this JMX in the cloud, from 25+ regions

Upload your JMeter script to LoadFocus and run it with thousands of virtual users from 25+ cloud locations, with no load generators to manage. Results show p95/p99 response times, throughput and errors per request, and a free tier is included.

JMeter Cloud Load Testing

Free API Load Test