The element that catches a value from one reply so the next request can use it.

The simple definition

A post-processor in JMeter is an element that runs right after a request and works with its response. The JSON Extractor is a post-processor made for responses written in JSON, the data format used by most modern web services. You give it a JSON path, which is a short address that points to one place inside the response, and a variable name. After each request, the extractor follows the path, takes the value it finds, and stores it in the variable.

From then on, any element in the test plan can use that variable by writing its name inside the variable placeholder syntax. A header can carry the token, a request body can carry the identifier, an address can include the item number, and an assertion can compare against it. This simple mechanism is the foundation of realistic API tests.

The family history

Before JMeter included this element, teams installed a plugin to get the same function, and many older plans still mention it. Current versions include the JSON Extractor in the standard installation. It uses a widely known JSON path library, so the path syntax you learn here works in many other tools as well.

Real journeys are full of values that nobody can know in advance.

A recorded or hand-written test often works on the first try with one user and then fails as soon as it runs again. The reason is almost always the same: some values in the recorded requests were created by the server during that session and are no longer valid. Replacing such values with fresh ones taken from live replies is called correlation. The JSON Extractor is the main tool for correlation in API tests.

What happens without correlation

If you hard-code a token from one run, the second run is rejected as unauthorised. If you hard-code an order number, every virtual user fights over the same order, or the server reports that it does not exist. Under load, the symptoms get worse: hundreds of users updating one item produce locks, conflicts and unrealistic cache hits. The test then measures how the system copes with a strange, unnatural pattern, not with real users.

JMeter offers several extractors. The best one depends on the format of the reply.

Extractors all do the same kind of job: read something from a response and store it in a variable. They differ in the language they use to point at the value. Choosing the one that matches the format of the reply gives simpler, faster and more reliable plans.

Why not just use a pattern?

Many beginners reach for the regular expression extractor out of habit, because it works on any text. On JSON it is risky. A pattern that finds the text after the word “token” breaks if the field order changes, if spaces are added, or if the same word appears elsewhere in the reply. A JSON path follows the structure instead of the text, so layout changes do not matter, and it points at exactly one field. For JSON replies, the JSON Extractor is almost always the right choice.

When the extractor runs decides what it can see, and where it sits decides what it touches.

JMeter runs the elements around a request in a fixed order: configuration elements, pre-processors, timers, the sampler, post-processors, assertions and listeners. The JSON Extractor is a post-processor, so it runs after the response has arrived and before assertions. This is important for two reasons. The extractor can only see the response of the sampler it belongs to. And the values it stores are ready before the next sampler starts, so the next request can use them at once.

flowchart TD
    A["Sampler sends the request and receives the reply"] --> B["JSON Extractor follows the path and stores the value"]
    B --> C["Assertions check the reply"]
    C --> D["Listeners record the result"]
    D --> E["Next sampler starts and can use the stored variable"]
        

Scope: which samplers the extractor serves

An extractor works on the samplers in its scope. As a child of a single sampler, it works only on that sampler. As a child of a controller or a thread group, it works on every sampler below. A broad extractor is convenient for a value that appears in every reply, but it also runs on replies that do not have the value, where it finds nothing and stores the default. Narrow scope is usually the safer choice.

A short refresher that makes every later chapter easier.

JSON describes data using only a few ideas. An object is a group of named fields, like a form. An array is an ordered list of items, like the lines on a receipt. A value is text in quotation marks, a number, true or false, the empty value called null, or another object or array. Objects and arrays can be nested inside each other to any depth.

flowchart TD
    R["Root object: the whole reply"] --> T["Field: token"]
    R --> U["Field: user, an object"]
    U --> UI["Field: id"]
    U --> UN["Field: name"]
    R --> O["Field: orders, an array"]
    O --> O1["Item 1: id, total"]
    O --> O2["Item 2: id, total"]
        

The building blocks of a path

A JSON path starts at the root, written as a dollar sign, and walks down by naming fields separated by dots. Square brackets pick items from arrays, counting from zero. A star selects every item, two dots search at any depth, and a filter in brackets keeps only the items that satisfy a condition.

The shape of your path decides whether you get one value or a list of values.

A path is called definite when it can point to at most one value. It names fields and exact array positions, nothing more. A path is called indefinite when it may match several values. It uses a star, a search at any depth, a filter, or a range of positions. This difference is small to read but large in effect, because it controls what the extractor stores and how the Match No. setting behaves.

Why the difference matters

With a definite path, the Match No. setting has little to decide, because there is only one candidate. With an indefinite path, Match No. becomes the main control. It tells the extractor whether to keep the first match, a random match, a specific numbered match, or all of them. Many beginner problems come from using an indefinite path and forgetting that the result is a list.

Choosing the narrowest path that works

Prefer the narrowest path that clearly points to what you need. A path such as $.data.token is easy to read and cheap to run. A path such as $..token searches the whole document and may match unrelated fields that happen to share the name. Narrow paths fail loudly when the structure changes, which is exactly what you want from a test.

Every box on the screen has a job. Knowing each one removes guesswork.

The element has a small number of fields. Each one is simple on its own, but the fields work together, and a small mistake in one of them changes the result of the others. Here is every field explained in plain words.

The pairing rule

The three list fields, names, paths and defaults, are paired by position. The first item of each belongs together. If you give three names and two paths, the third name has nothing to read. If you give two defaults for three names, the last variable gets no safe fallback. Always keep the three lists the same length and in the same order.

flowchart LR
    N["Names: token ; userId ; role"] --> P1["Pair 1: token"]
    J["Paths: $.token ; $.user.id ; $.user.role"] --> P1
    D["Defaults: NO_TOKEN ; NO_USER ; NO_ROLE"] --> P1
    P1 --> V["Variables token, userId, role"]
        

One small number decides how a list of matches becomes variables.

When a path finds more than one value, the extractor needs a rule. The Match No. field is that rule. It is one of the most important settings in the element, and it is also one of the easiest to misread. Here are the choices.

Why random is useful

Real users do not all buy the same product. If every virtual user opens the first item, the test hits the same database rows and the same cache entries, which makes results look better than reality. Choosing a random match spreads the load across the data, which is closer to real behaviour.

Why all is powerful

With minus one, the extractor stores every match as a numbered variable and also stores how many it found. That count lets a loop walk through the list. This is the base of many realistic journeys, such as opening every product on a search page or deleting every item in a basket.

One extraction can leave several variables behind. Knowing their names avoids confusion.

For a variable name such as itemId, the extractor can create several related variables. Which ones appear depends on Match No. and on the concatenation option. The table below lists them.

Reading the count

The count variable is the quiet hero. It tells you whether anything was found at all. A count of zero means the path matched nothing, even if the main variable holds a default. A loop uses it as the upper limit, and an assertion or an If Controller can use it to branch the journey.

Leftover variables from earlier runs

Numbered variables from a previous iteration can survive when the new reply is shorter. If the first reply had five items and the second only three, positions four and five may still hold old values unless the extractor clears them. Always trust the count, not the existence of a numbered variable.

flowchart TD
    A["Path finds 3 values"] --> B{"Match No."}
    B -->|"1"| C["itemId = first value"]
    B -->|"0"| D["itemId = random value"]
    B -->|"-1"| E["itemId_1, itemId_2, itemId_3 and itemId_matchNr = 3"]
    E --> F["Optional itemId_ALL = joined list"]
        

A good default turns a silent problem into a visible one.

If the path finds nothing, the extractor stores the default value. If you leave the default empty, the variable may not be set at all, or may keep an old value from a previous iteration. Both cases are dangerous, because the next request then sends something wrong, and the failure appears far from its cause.

Choose obviously fake defaults

A good default is easy to spot in logs and impossible to confuse with real data. Values such as NOT_FOUND, NO_TOKEN or MISSING_ORDER_ID are clear. A default such as zero or one looks like a real identifier, and the server may even answer normally for it, which hides the problem completely.

Guarding the next step

A default value alone does not stop the journey. Add a check that fails fast when the default appears. A response assertion on the extractor’s own request, or an If Controller that skips dependent steps when the variable equals the default, keeps the test honest and the results clean.

One extractor can read many fields, and it can read from different sources.

You do not need a separate extractor for every value. A single element can read several fields from the same reply. This keeps the plan compact and makes it easier to see everything that one request produces. The rule is simple: give a list of names, a list of paths and a list of defaults, all separated by semicolons and all in the same order.

When to group and when to split

Group values that come from the same reply and serve the same purpose, such as the token and the user identifier from a login. Split values when they have different match rules, for example one random product and the full list of all products. Because Match No. and the concatenation option apply to the whole element, values that need different settings belong in different elements.

The Apply to setting

Most of the time the extractor reads the response of the request it belongs to. The Apply to field changes this. A request may have sub-requests, for example embedded resources fetched after a page. You can choose to read only the main reply, only the sub-replies, or both. You can also tell the extractor to read a JMeter variable instead of a reply. That last option is helpful when a value was already stored and holds a JSON text that you want to dig into further.

JMeter variables hold text. Understanding this prevents many small surprises.

Whatever the extractor finds, the stored variable is text. A number in the reply becomes the text of that number. A true or false value becomes the words true or false. This is fine for most uses, because later requests are text anyway. It matters when you do arithmetic or compare values, because you must convert the text back to a number in that step.

Objects and arrays as text

If the path points to an object or an array, the stored variable contains a JSON text of that part. This is useful when you want to pass a whole block to the next request, such as an address object copied from one reply into a new order. It is also a way to cut a big reply into smaller pieces for later extractors. Keep in mind that the text may be formatted differently from the original, so do not compare it character by character with the raw reply.

Numbers and formats

Very large identifiers and decimals can look different after being parsed and written back. If an identifier is a long number, check it in a debug view and, if the format changes, ask the service owners whether the field should be a text field. Silent changes in digits are rare, but they are painful to find.

Extraction is only half the job. The other half is using the value in the right place.

Once a variable exists, you use it by writing its name inside a dollar sign and curly braces in any later field. That includes the path of a request, a query parameter, a header, a request body, an assertion or even another extractor. JMeter replaces the placeholder with the stored text just before sending.

Scope: who can see the variable

A variable belongs to the virtual user that created it. Another virtual user cannot see it. This is a good thing, because each user gets their own token and their own order identifier. It also means a value extracted in one thread group cannot be read in another thread group directly. If you need to share a value across groups, a property is the usual route, and it needs care, which a later chapter explains.

Order of use

The extractor runs after its own request, so its variable is ready for the next request in the sequence. It is not ready for the same request, because that request has already been sent. If a value is needed in the very first request, it must come from somewhere earlier, such as a data file or a setup step.

sequenceDiagram
    participant U as Virtual user
    participant S as Server
    U->>S: Request 1, login
    S-->>U: Reply with token
    Note over U: Extractor stores token
    U->>S: Request 2 sends stored token
    S-->>U: Reply for that user
        

A realistic story shows how each extractor feeds the next request.

Let us follow a simple but typical journey for a task management service. The user logs in, creates a task, reads the task back, and deletes it. Three values travel between steps: the access token, the new task identifier and, for checking, the title of the task. Each step has an extractor that prepares the next one.

flowchart LR
    A["Login"] -->|"token"| B["Create task"]
    B -->|"taskId"| C["Read task"]
    C -->|"taskId"| D["Delete task"]
    A -.->|"token in header"| C
    A -.->|"token in header"| D
        

What this teaches

Every arrow in the picture is an extraction on the sending side and a use on the receiving side. When something fails, you can follow the arrows backward. If the delete step fails with a missing identifier, you look at the create step’s extractor. If every step fails, you look at the login. This makes problems small and local, which is the whole point of designing journeys as chains.

When you extract all matches, a loop lets you act on each of them.

Suppose a search reply contains twenty product identifiers and your user should open each one. The extractor, with Match No. set to minus one, creates numbered variables and a count. The ForEach Controller then walks through those numbered variables one by one, running its child requests each time with the current value ready.

The fields that matter

Limiting the loop

Real shoppers do not open every item. If a search returns a hundred products, you may want only the first five. Set the end index to a small number and keep the count as a safety limit. Be careful that the end index does not exceed the real count, because the loop would then read variables that do not exist and send placeholder text to the server.

flowchart TD
    A["Search request"] --> B["Extractor, Match No. -1: productId_1 ... productId_N and count"]
    B --> C["ForEach Controller: prefix productId"]
    C --> D["Open product request uses current value"]
    D --> C
    C --> E["Loop ends, continue to checkout"]
        

Some journeys do not know in advance how many steps they need. The reply decides.

Two common situations need a loop that depends on a reply. The first is pagination. A service returns a list in pages, and each reply carries a marker that points to the next page. The second is polling. A service starts a job in the background, and the user must ask again and again until the job is done. In both cases an extractor reads a field from the reply, and a loop condition uses that field to decide whether to continue.

Pagination step by step

The first request asks for the first page. The extractor stores the next-page marker, with a default that means “no more pages”, for example an empty marker that the loop condition understands. The loop condition checks the variable. While a marker exists, the loop runs the next page request using the marker. When the reply no longer contains a marker, the extractor stores the default, the condition becomes false, and the loop ends.

flowchart TD
    A["First page request"] --> B["Extractor reads next marker, default is empty"]
    B --> C{"Marker has a value?"}
    C -->|"Yes"| D["Request next page with marker"]
    D --> B
    C -->|"No"| E["Loop ends"]
        

Polling step by step

Polling is similar. The start request returns a job identifier. A loop then calls the status request. The extractor reads the status field, and the loop continues while the status says the job is still running. A short pause between calls prevents hammering the service. When the status says done or failed, the loop ends, and an assertion checks that the final status is the expected one.

Always add a safety limit

A loop that depends only on a reply can run forever if the reply never changes. A bug in the service, a wrong path in your extractor, or a default that equals a real value would trap your virtual user inside the loop. Add a second condition, such as a counter that stops the loop after a fixed number of rounds. Treat reaching that limit as a test failure, because the journey did not complete in a reasonable time.

Real users choose different things. Your extractor can imitate that.

Load tests are only as honest as the data they use. If every virtual user opens the same product, edits the same record, or searches the same word, caches and databases behave in a way that real traffic never would. The extractor’s random mode helps by choosing one match at random from a list that the server just provided. Because the list comes from the server, every choice is valid at that moment.

Where random choice helps

Combining random choice with filters

A random pick from an unfiltered list may select an item that cannot be used, such as a product that is out of stock. A filter inside the path removes those items before the random choice happens. In this way the extractor only draws from valid candidates, and your later requests rarely fail for business reasons that have nothing to do with performance.

flowchart LR
    A["Server returns 40 products"] --> B["Path filter keeps 25 in-stock products"]
    B --> C["Match No. 0 picks one at random"]
    C --> D["Variable productId holds the chosen value"]
    D --> E["Next request opens that product"]
        

Weighing randomness against repeatability

Random choices make a run differ from the previous one. For comparing two builds, differences that come from random picks can look like differences in the product. Two habits reduce this problem. Use large enough runs, so that the randomness averages out. And log the chosen values in a debug view during a small trial, so you can reproduce a surprising failure by feeding the same value manually.

Tokens are the most common extracted value, and the most common source of long-run failures.

Most modern services give a short-lived token after login. Every later request carries it. The extractor captures it once, and a header manager sends it on each call. This pattern is simple for a two-minute test, and it becomes interesting in a two-hour test, because tokens expire. If the test ignores expiry, the second half of the run fails with authorization errors that say nothing about the performance of the service.

Three ways to handle expiry

Capturing the expiry too

Many services return the token and a lifetime in seconds, or an expiry time. Extract both with one element. A small calculation can then store the time at which a refresh is due, and an If Controller can compare it with the current time before each request. This keeps the test running smoothly for hours, and it mirrors how real clients behave.

flowchart TD
    A["Login, extract token and lifetime"] --> B["Work requests with token"]
    B --> C{"Token close to expiry?"}
    C -->|"No"| B
    C -->|"Yes"| D["Refresh call, extract new token"]
    D --> B
        

A shared token for everyone

Sometimes a test uses one token for all virtual users, for example a service account. This is simpler, and it is also less realistic, because the server sees one identity with a very high request rate and may throttle it. If the real system has many users, the test should use many tokens, one per virtual user, each captured by its own login.

The extractor takes a value. The assertion proves the value was worth taking.

An extractor and an assertion often read the same path, and they have different jobs. The extractor stores a value for later. The assertion says whether the reply was correct. If you use only the extractor, a failed extraction quietly stores the default and the problem appears later. If you add an assertion on the same path, the failure appears on the request that caused it, with a clear name.

The standard pairing

For every value you extract and later depend on, add an existence check on the same path. For identifiers, this is usually enough. For values that must have a meaning, such as a status, add an equals check as well. With this pair in place, a missing token, an empty list, or a changed field name stops the journey early at the exact request that produced it.

Why not just rely on the default?

A default can only protect the next request. It cannot tell the report that this request, the one that should have returned the value, was the real culprit. The assertion gives the failure a home. The result is shorter investigations, cleaner error counts and fewer arguments about whether a failure belongs to the test or the system.

A few simple tools show exactly what the extractor saw and what it stored.

An extractor that has not been tested on real data is only a guess. Fortunately, JMeter gives several ways to see what is happening. Use them every time you add or change an extractor, and again after any service change.

The tools you can use

A short routine for each new extractor

First, run the request once with a single thread and look at the real reply. Second, test the path in the path tester and confirm that it finds exactly what you expect, nothing more and nothing less. Third, add a debug view and confirm that the variable holds the right value. Fourth, break the path on purpose and confirm that the variable shows your obviously fake default. Finally, remove or disable the debug elements before a large run, because they cost memory and time.

flowchart LR
    A["Run one request"] --> B["Test path in the path tester"]
    B --> C["Check variable in a debug view"]
    C --> D["Break the path on purpose"]
    D --> E["Confirm the default appears"]
    E --> F["Disable debug elements for the real run"]
        

The JSON Extractor is a great default, but it is not the only tool in the box.

JMeter offers several ways to pull a value from a reply. The right one depends on the format of the reply and on how complex the rule is. For structured JSON replies, the JSON Extractor is almost always the clearest and most readable choice. For other formats, or for unusual rules, another tool may fit better. Knowing the options helps you choose without hesitation.

A simple decision path

If the reply is valid JSON, start with the JSON Extractor. If your rule needs a calculation, or the path language cannot express it, consider a script step, but keep it small. If the reply is not JSON, choose the tool made for that format. If a reply mixes formats, such as JSON inside a text line, extract the outer part first with a boundary or a pattern, and then use the JSON Extractor on the variable with the Apply to setting.

flowchart TD
    A["What is the reply format?"] --> B{"Valid JSON?"}
    B -->|"Yes"| C["JSON Extractor"]
    B -->|"No, XML or HTML"| D["XPath or CSS Selector Extractor"]
    B -->|"No, plain text or headers"| E["Boundary or Regular Expression Extractor"]
    B -->|"Mixed"| F["Cut out the JSON part first, then JSON Extractor on the variable"]
        

A small element repeated thousands of times per second is no longer small.

Every extraction reads the reply, parses it as a document, and evaluates a path. With one user this takes a tiny fraction of a millisecond. With hundreds of users and thousands of requests per second, the sum becomes visible in the CPU and memory of the load generator. If the generator is busy, it measures its own delay as response time, and your results become less trustworthy.

What drives the cost

Practical ways to keep the cost low

Extract only what a later step truly needs. Use exact paths instead of searches. Avoid storing whole objects when one field is enough. Remove extractors that nobody uses any more, which is common in plans that have grown over time. For big replies that you only need to pass along, think about whether the later request can ask the server for a smaller reply instead.

Measuring the effect

The honest way to know is to measure. Run the same test with the extractors enabled and disabled at a moderate load, and compare the CPU and memory of the generator and the response times. If the difference is small, you are safe. If it is large, trim the work or add more generator machines. Keep the CPU of a generator below a comfortable level, so that the timings stay a measure of the service, not of the tool.

Where a variable lives decides who can see it. This matters more when many machines are involved.

In a distributed test, one controller machine sends the same plan to several worker machines. Each worker runs its own virtual users, and each virtual user has its own variables. A value extracted on one worker is not visible on another, and a value extracted by one user is not visible to another user. For most journeys this is exactly what you want, because each user logs in and works with their own data.

Variables and properties

Sharing a value inside one machine

Sometimes a setup step logs in once, and every user should use that result. A property can carry it. A small script step copies the extracted variable into a property in the setup group, and the main group reads the property into a variable at the start. This pattern is useful, and it must be used with care. Properties are global to the process, so only one source should write them, and users should only read them.

Sharing across worker machines

Each worker runs the setup step itself, so each worker gets its own value. If the service requires a single shared token for the whole test, the setup values must be consistent, for example by giving the token through a command-line option to every worker. Otherwise, let each worker log in separately, which is simpler and often more realistic.

flowchart TD
    C["Controller sends the plan"] --> W1["Worker 1: own users, own variables"]
    C --> W2["Worker 2: own users, own variables"]
    W1 --> S1["Setup step: login, property on worker 1"]
    W2 --> S2["Setup step: login, property on worker 2"]
    S1 --> U1["Users on worker 1 read property"]
    S2 --> U2["Users on worker 2 read property"]
        

Extracted values are often secrets. Treat them as carefully as the real system would.

The values that testers extract are often the most sensitive ones in the whole exchange: access tokens, session identifiers, customer identifiers and sometimes personal data. Because JMeter stores variables in memory and can write them to files and reports, a careless setup spreads secrets to places where they do not belong.

Where secrets can leak

Good habits

Use dedicated test accounts and synthetic data, never real customer data. Use short-lived tokens, and rotate them. Keep real credentials out of plan files by reading them from protected sources at run time. Mask or remove values before sharing a report or a screenshot. Delete result files that contain secrets when the investigation ends, and apply the same retention rules your company uses for other sensitive files.

flowchart LR
    A["Token extracted into a variable"] --> B["Used in headers of later requests"]
    A --> C{"Where else might it go?"}
    C --> D["Result file"]
    C --> E["Debug view and logs"]
    C --> F["Failure messages"]
    C --> G["Saved plan defaults"]
    D --> H["Limit what is saved and mask before sharing"]
    E --> H
    F --> H
    G --> H
        

A few reusable habits make extraction plans clean, fast to debug and easy to hand over.

Patterns are proven answers to common problems. They save time, because you do not invent a new approach each time, and they help a team read each other’s plans. Here are the patterns that serve JSON extraction best.

Naming conventions

Agree on a naming style and keep it. Short, meaningful, lower camel case names such as authToken, orderId and productIds are easy to read. Name elements by what they extract: “Extract authToken from login”. When someone reviews the plan a year later, the names tell the story without opening a single element.

A map of the plan

For larger plans, keep a one-page map listing every variable, where it is extracted, where it is used and what happens when it is missing. It takes an hour to create and saves days of confusion, especially when new people join the team or when the service changes its replies.

These habits look harmless and cause long, confusing investigations.

An anti-pattern is a solution that seems reasonable and keeps causing trouble. Learning to recognise them is the fastest way to improve a plan. Each box below names the problem, explains the harm and shows the better way.

A short list you can follow every time you add an extractor to a plan.

Best practices are the habits of experienced testers, collected in one place. None of them is hard. Together they make plans that are faster to build, easier to read and much less likely to fail in mysterious ways.

Four common kinds of systems, and how the extractor supports each of them.

Ideas become clearer when we see them in familiar settings. Here are four systems that testers meet again and again, and the extraction needs of each.

A calm, step-by-step approach finds the cause of most extraction problems in minutes.

When an extractor does not work, the symptom is usually the same: the variable holds the default value, holds an old value, or holds something unexpected. The cause is almost always one of a short list. Work through the list from top to bottom.

The five-question routine

flowchart TD
    A["Variable wrong or empty"] --> B{"Is the reply valid JSON?"}
    B -->|"No"| C["Fix the request or the environment first"]
    B -->|"Yes"| D{"Does the path find the value in the path tester?"}
    D -->|"No"| E["Correct the path"]
    D -->|"Yes"| F{"Do names, paths and defaults line up?"}
    F -->|"No"| G["Fix the lists, remove hidden spaces"]
    F -->|"Yes"| H{"Is the variable used after it is created?"}
    H -->|"No"| I["Reorder steps or move the extractor"]
    H -->|"Yes"| J["Check scope, properties and server limits"]
        

Most problems end at the first or second question. A reply that is not valid JSON is the single most common cause, because overloaded services often return an HTML error page with the same status code that the extractor expected to see on a good day. The path itself was fine, and the reply simply was not what you thought it was.

Why the first question matters most

Many testers spend an hour adjusting a path that was never wrong. The server returned an error page, a login screen or an empty body, and the path simply had nothing to read. Looking at the real reply first costs ten seconds and removes the most common false trail. Keep the habit: before touching any setting, open the reply that the extractor actually received and read it with your own eyes.

The second most common cause is timing. The extractor reads the reply of its own request, so it must sit under the request that produces the value, not under a neighbour. When an element is moved or copied in a large plan, its place in the tree changes silently, and it may start reading a reply that does not hold the field. A quick look at the tree structure, and at the name of the request above the extractor, confirms that the right pair is together.

Extractors depend on the shape of replies, and replies change. A small routine keeps plans healthy.

An extractor is a quiet promise: “the value you need lives at this address.” When the service changes its reply, the promise can break without any visible error in the plan itself. A short check before each important run, and a regular review after each release, keeps the promise honest and protects your results.

Habits that keep plans healthy

Keep a small library of known good samples

Teams that test often benefit from a folder of sample replies, one healthy and one broken for each important request. With these files you can try a new path in seconds, show a colleague exactly what the service returned on a bad day, and review changes without touching a live environment. Samples also work as living documentation. A new tester can read them and understand the journey faster than from any written description, because they show real field names, real nesting and real values.

Small details can differ between versions. Verify on your own installation.

JMeter and its path library evolve. Details such as how a null is stored, how a numeric value is written back, which functions are available inside a path, or which related extractors ship with the tool can differ between versions. This guide describes the general behaviour that holds across common recent versions, and it avoids promising exact details that may change.

What to verify on your version

A one-page compatibility test

Keep a tiny test plan with a few sample replies and the extractors you rely on. Run it whenever you upgrade the tool or move to a new machine. If any variable changes its value or format, you know before your real tests do. This small habit has saved many teams from chasing a “service problem” that was really a tool upgrade.

Short, plain answers to the questions testers ask most often.

It reads a reply, follows one or more paths to find values, and stores them in variables that later requests, assertions and controllers can use.

Whenever a later request depends on something the server created in an earlier reply, such as tokens, identifiers, page markers and status values.

Give lists of names, paths and defaults, separated by semicolons and in the same order. The first name pairs with the first path and the first default.

It decides which match to keep when a path finds several: a positive number for that numbered match, zero for a random one, and minus one for all matches with a count variable.

The path found nothing. Most often the reply was not what you expected, such as an error page, or the path has a spelling, case or position mistake. Test the path in the path tester on the real reply.

A clearly fake value such as NOT_FOUND, never something that looks real like zero or one, and never an empty value.

Set Match No. to minus one, then use a ForEach Controller with the variable name as the prefix, a start index of zero, an end index equal to the count or a smaller limit, and the underscore option ticked.

Text. Convert them in a later step when you need arithmetic or numeric comparison.

Not directly. Variables belong to one user. Shared values can travel through properties, which are visible to all users on the same JMeter process but not across worker machines.

Yes, whenever a later step depends on the value. An existence check on the same path makes failures appear on the request that caused them.

A little. Each extraction parses the reply. Use exact paths, extract only what you need, and compare generator load with and without extractors.

Log in again each iteration, refresh before the lifetime ends using an extracted expiry, or react to an authorization failure with one new login. Pilot the test for longer than the token lifetime.

The short version, for the day you only have two minutes.

The JSON Extractor is the bridge between one reply and the next request. It reads a path, stores the result in a variable and lets your journey follow real data instead of fixed guesses. Used with care, it makes tests realistic, repeatable and easy to debug. Used carelessly, it hides failures behind stale or fake values.