Advanced Cookie Configuration (cookies.cfg)¶
Beyond extractors/processors: If your application requires browser-specific cookie values that can't be extracted from responses, you'll need the cookies.cfg file. This is rare; most cookie handling is automatic or solved with extractors/processors. For the extractor/processor workflow, see JavaScript Cookies.
When You Need cookies.cfg¶
You'll know you need cookies.cfg if:
- Application checks a cookie value to determine browser type (e.g.,
BROWSERSUPPORT=yesvs.BROWSERSUPPORT=no) - Cookie value must be set by the client with no server-provided value to extract
- You need to override a cookie value that the server sets (unusual, but sometimes required for testing edge cases)
- Different virtual users need different cookie values to simulate browser diversity
Example scenario: Legacy enterprise application checks BROWSERSUPPORT cookie to decide whether to send modern JavaScript or fallback HTML. During recording, your browser sets BROWSERSUPPORT=yes, but Load Tester doesn't automatically set this browser-specific cookie, so replay receives the fallback HTML and fails.
Configuration File Format¶
The cookies.cfg file uses a simple text format to define cookie override rules. Each rule specifies the cookie name, when to apply the rule, and what value to use.
File location: Create cookies.cfg in Load Tester's custom configuration directory:
- Windows:
C:\Users\<username>\WebPerformance7\config\cookies.cfg - macOS/Linux:
~/WebPerformance7/config/cookies.cfg
See Configuration Files Reference for the exact path on your system.
File format: Plain text, one rule per cookie, rules are numbered sequentially (cookie1, cookie2, etc.):
Or with dataset:
cookie2.name=COOKIENAME
cookie2.instance=1
cookie2.setFromDataset=dataset-name
cookie2.setFromField=column-name
Configuration Parameters¶
| Parameter | Required | Description | Example Values |
|---|---|---|---|
cookieN.name |
Yes | Cookie name as it appears in HTTP headers | BROWSERSUPPORT, sessionid, tracking |
cookieN.instance |
Yes | Which occurrence of the cookie to override (1 = first time it appears) | 1, 2, 3 |
cookieN.setFromConstant |
Conditional | Fixed value to use for all virtual users (mutually exclusive with setFromDataset) |
yes, supported, v1.2.3 |
cookieN.setFromDataset |
Conditional | Dataset name containing cookie values (requires setFromField) |
browser-types, session-ids |
cookieN.setFromField |
Conditional | Dataset column name containing cookie values (requires setFromDataset) |
browserSupport, token |
Numbering rule: Each cookie rule must use a unique number (cookie1, cookie2, cookie3, etc.). If you skip a number, Load Tester ignores all rules after the gap.
Instance rule: If a cookie appears multiple times in a test case (e.g., server renews session cookies), use instance=1 to override the first occurrence, instance=2 for the second, etc. Most scenarios use instance=1 because you want the override to apply from the first occurrence onward.
Example 1: Fixed Browser Support Cookie¶
Scenario: Application expects BROWSERSUPPORT=yes to enable modern features.
cookies.cfg:
What this does:
- Whenever the test case sends a cookie named
BROWSERSUPPORT, Load Tester replaces the value withyes - Applies starting from the first occurrence (
instance=1) - All virtual users send the same value
Example 2: Browser Diversity Using Dataset¶
Scenario: Simulate a mix of browsers by varying the USER_AGENT_TYPE cookie. You have a dataset with different browser identifiers.
Dataset (browser-types dataset):
| browserType |
|---|
| chrome |
| firefox |
| safari |
| edge |
cookies.cfg:
cookie1.name=USER_AGENT_TYPE
cookie1.instance=1
cookie1.setFromDataset=browser-types
cookie1.setFromField=browserType
What this does:
- Each virtual user gets a different
USER_AGENT_TYPEvalue from the dataset - Simulates browser diversity during load testing
- Virtual user 1 sends
USER_AGENT_TYPE=chrome, virtual user 2 sendsUSER_AGENT_TYPE=firefox, etc.
See Datasets & Data-Driven Testing for details on creating datasets.
Example 3: Multiple Cookie Overrides¶
Scenario: Override both BROWSERSUPPORT and TRACKING_CONSENT cookies.
cookies.cfg:
cookie1.name=BROWSERSUPPORT
cookie1.instance=1
cookie1.setFromConstant=yes
cookie2.name=TRACKING_CONSENT
cookie2.instance=1
cookie2.setFromConstant=accepted
What this does:
- Sets
BROWSERSUPPORT=yesstarting from the first occurrence - Sets
TRACKING_CONSENT=acceptedstarting from the first occurrence - Both overrides apply to all virtual users
Applying Configuration Changes¶
After editing cookies.cfg:
- Save the file (plain text, no formatting)
- Restart Load Tester (changes only take effect on startup)
- Run a replay to verify the cookies are set correctly
- Check Headers View to confirm cookie values in HTTP requests
Do NOT attempt to reload the configuration file while Load Tester is running. The file is read once at startup.
Troubleshooting¶
Configuration File Changes Don't Take Effect¶
Symptom: You edited cookies.cfg (or hosts.txt), but Load Tester still uses the old behavior.
Likely causes:
- Load Tester not restarted (configuration files are read at startup only)
- Wrong file location (file is in the wrong directory)
- File permissions wrong (Load Tester can't read the file)
- Syntax errors in file (Load Tester ignores malformed configuration)
Solution:
- Restart Load Tester after editing configuration files
- Verify file location: Use Tools → Preferences → Load Tester → Configuration Files to see the exact path
- Check file permissions: Ensure the file is readable (not locked, not admin-only)
- Validate syntax: Check for typos, incorrect numbering (
cookie1,cookie2with no gaps), or malformed entries
Ask the AI to Generate cookies.cfg Configuration
If you're unsure about the cookie name, instance number, or syntax:
I need to override the BROWSERSUPPORT cookie to always send "yes". Can you
show me the exact cookies.cfg configuration and where to put the file?
The AI can:
- Generate the exact
cookies.cfgsyntax for your scenario - Determine the correct instance number by analyzing your test case
- Create datasets if you need cookie values to vary per virtual user
- Verify the file location and restart procedure
- Troubleshoot issues if cookies aren't being overridden