JMeter Correlation: Capture Dynamic Session Tokens (2026)

JMeter can’t just record dynamic session tokens; it needs explicit instructions on how to find and reuse them.

Let’s watch JMeter in action. Imagine a login flow.

1. Login Request: You hit a login endpoint, say POST /login.
2. Response: The server responds with a JSON payload containing your user data and, crucially, a session token, like:

   {
     "user": { "id": 123, "name": "Alice" },
     "sessionToken": "a1b2c3d4e5f67890"
   }
   

3. Subsequent Request: You then make a request to a protected endpoint, like GET /profile, and you must include that sessionToken in the headers or as a parameter for the server to recognize you.

Without correlation, JMeter records the literal session token from the first login. Every subsequent request in that thread will use that stale token, and the server will reject them with an authentication error. Correlation tells JMeter: "Hey, that sessionToken value you just got? Save it. For all future requests from this user, use this saved value instead of a hardcoded one."

Here’s how you set it up:

First, you need to extract the dynamic value. Add a "PostProcessor" to your login request sampler. The most common one is the "Regular Expression Extractor."

• Name of newly created field: sessionToken (This is the variable name you’ll use later).
• Regular Expression: "sessionToken":"(.*?)"
  • "sessionToken":" : Matches the literal string "sessionToken":"
  • (.*?) : This is the capture group.
    • . : Matches any character (except newline).
    • * : Matches the previous character zero or more times.
    • ? : Makes the * quantifier "lazy" or "non-greedy." It will match the shortest possible string. This is crucial to avoid capturing more than just the token if the pattern appears multiple times.
  • " : Matches the closing quote.
• Template: $1$
  • This tells JMeter to use the content of the first (and in this case, only) capture group (.*?) as the value for our variable.
• Match No.: 1
  • This specifies which occurrence of the pattern to use. 1 means the first match found.

Now that you’ve extracted the sessionToken into a JMeter variable named sessionToken, you need to use it in your subsequent requests. Go to the sampler for your protected endpoint (e.g., GET /profile).

Instead of hardcoding the session token in the "Headers Manager" or "HTTP Request" parameters, use the JMeter variable syntax: ${sessionToken}.

For example, if you were sending it in a header named Authorization:

• Header Name: Authorization
• Header Value: Bearer ${sessionToken}

If you were sending it as a parameter in a GET request:

• Parameter Name: token
• Parameter Value: ${sessionToken}

The beauty of this is that JMeter, by default, will automatically reuse the last value assigned to ${sessionToken} for each thread. If your test plan involves multiple users logging in independently, each thread will get its own unique session token and use it correctly for its subsequent requests.

The most common mistake people make is not using a lazy quantifier (?) in their regular expression, leading to incorrect extraction if the token pattern appears elsewhere in the response. Another is forgetting to add the "Regular Expression Extractor" to the request that returns the token, not the request that needs it.

The next hurdle you’ll likely face is handling tokens that expire and need to be refreshed, requiring a separate "refresh token" flow.