JMeter JSON Extractor Tutorial with Examples

TL;DR

Add a JSON Extractor under the response-producing sampler, enter a JSONPath expression such as $.session.token, set Match No. to 1, and reuse the created variable as ${sessionToken}. Assert the extraction and the downstream response so a missing or stale value fails visibly.

Key Takeaways

• Attach each JSON Extractor to the sampler that produces its response.
• Use explicit JSONPath expressions and Match No. 1 for a single intended value.
• Use Match No. -1 to create indexed variables for every array match.
• Set visible sentinel defaults and fail when a required field is absent.
• Verify a chained value in the downstream request and response, not only in the producer.
• Debug with one GUI thread, then run the saved plan in CLI mode.

A JMeter JSON Extractor tutorial should end with a value from one response controlling a later request. Here you will capture a session token, select a product ID from a nested JSON array, create an order with that ID, and read the order back. Each handoff has a check, so an HTTP 200 alone cannot hide a broken JSONPath expression.

The local API resets on restart. Once the flow works with one JMeter thread, adapt the pattern to your service. For test-plan basics, see the JMeter tutorial for beginners.

What You Will Build

Create a JMeter test plan with four HTTP Requests: 01 Create session, 02 List products, 03 Create order, and 04 Read order. The first response yields sessionToken. The product list yields selectedSku and, separately, all available SKUs. The create response yields orderId. The read request then proves that the stored order refers to the selected SKU.

You will inspect match numbers, defaults, and generated variables. Build with one user and one iteration, then run the saved .jmx file in CLI mode.

The official JSON Extractor reference defines the fields used below. The JMeter getting started guide recommends GUI mode for creating a plan and CLI mode for load execution.

Prerequisites

Use the official Apache JMeter 5.6.3 binary release and a Java installation supported by that release. The Apache download page lists 5.6.3 and Java 8 or newer as of this article's publication date. Java 17 or newer is recommended in the JMeter change notes; your installed JDK can be newer. If Apache publishes another release, use the version you installed and follow that release's Java requirement. Node.js is needed only for the local sample API; use a maintained installed release rather than a package pin.

Check the exact versions on your machine before building the plan:

java -version
node --version
jmeter --version

If jmeter is not on PATH, run ./bin/jmeter --version from your unpacked JMeter directory (or bin\jmeter.bat --version on Windows). Record those outputs with the plan. Do not assume the tutorial's release is the version on an existing workstation. You also need a terminal, curl, and a free loopback port 3100. The shell snippets use a POSIX shell; Windows users can create server.mjs in an editor and run the same Node command.

Verification command: java -version && node --version && jmeter --version should print three version outputs. If the last command is unavailable, use the launcher path from the directory you installed. The GUI must open before you begin configuring samplers.

Step 1: Start a Local JSON API

Save this server in an empty scratch directory as server.mjs. It exposes stable catalog data and creates fresh session and order IDs. The token is checked on every endpoint except session creation. The local responses are deterministic except for generated IDs.

mkdir -p jmeter-json-extractor-lab
cd jmeter-json-extractor-lab
cat > server.mjs <<'EOF'
import http from 'node:http';
import { randomUUID } from 'node:crypto';

const products = [
  { sku: 'QA-BOOK', name: 'QA Workbook', price: 20 },
  { sku: 'LOAD-KIT', name: 'Load Test Kit', price: 35 }
];
const sessions = new Set();
const orders = new Map();

function send(res, status, data) {
  res.writeHead(status, { 'Content-Type': 'application/json' });
  res.end(JSON.stringify(data));
}

async function readBody(req) {
  let raw = '';
  for await (const part of req) raw += part;
  try { return JSON.parse(raw); } catch { return null; }
}

http.createServer(async (req, res) => {
  const path = new URL(req.url, 'http://127.0.0.1:3100').pathname;
  if (req.method === 'POST' && path === '/sessions') {
    const token = randomUUID();
    sessions.add(token);
    return send(res, 201, { session: { token }, status: 'ready' });
  }

  const token = req.headers.authorization?.replace(/^Bearer /, '');
  if (!sessions.has(token)) return send(res, 401, { error: 'unauthorized' });

  if (req.method === 'GET' && path === '/catalog') {
    return send(res, 200, { data: { products }, count: products.length });
  }
  if (req.method === 'POST' && path === '/orders') {
    const input = await readBody(req);
    if (!input || !products.some(p => p.sku === input.sku) ||
        !Number.isInteger(input.quantity) || input.quantity < 1) {
      return send(res, 400, { error: 'invalid order' });
    }
    const order = { id: randomUUID(), sku: input.sku,
      quantity: input.quantity, state: 'created', owner: token };
    orders.set(order.id, order);
    return send(res, 201, { order: {
      id: order.id, sku: order.sku,
      quantity: order.quantity, state: order.state
    } });
  }
  const match = path.match(/^\/orders\/([^/]+)$/);
  if (req.method === 'GET' && match) {
    const order = orders.get(match[1]);
    if (!order || order.owner !== token) {
      return send(res, 404, { error: 'not found' });
    }
    return send(res, 200, { order: {
      id: order.id, sku: order.sku,
      quantity: order.quantity, state: order.state
    } });
  }
  return send(res, 404, { error: 'not found' });
}).listen(3100, '127.0.0.1', () => {
  console.log('JSON API ready at http://127.0.0.1:3100');
});
EOF
node server.mjs

Leave this process running. A restart clears sessions and orders, so any ID extracted before a restart becomes stale. The catalog remains the same because it is defined in code. A later 401 or 404 may reflect that restart.

Verification command: from another terminal, run curl -i -X POST http://127.0.0.1:3100/sessions. Expect HTTP 201 and JSON containing session.token. Run it again and notice that the token changes. A connection refusal means the Node process exited or another service owns port 3100. If you change the port, make the same change in the server's URL and every JMeter request.

Step 2: JMeter JSON Extractor Tutorial for a Session Token

Open JMeter. Add a Thread Group to the Test Plan with Number of Threads 1, Ramp-up Period 1, and Loop Count 1. Add an HTTP Request Defaults element under the Thread Group. Set Protocol to http, Server Name or IP to 127.0.0.1, and Port Number to 3100. This keeps the four requests focused on paths and methods. Save the plan as json-extractor-lab.jmx in your scratch directory.

Under the Thread Group, add an HTTP Request named 01 Create session. Set Method to POST and Path to /sessions. Add a JSON Extractor as a child of that sampler through Add > Post Processors > JSON Extractor. Configure it as follows:

Apply to: Main sample only
Names of created variables: sessionToken
JSON Path Expressions: $.session.token
Match Numbers: 1
Default Values: MISSING_TOKEN
Compute concatenation var: unchecked

The path reads session.token from the response root. Set Match No. to 1 explicitly: an empty field defaults to random selection (0) if the path later returns several results. MISSING_TOKEN is a diagnostic sentinel, not a credential.

Add View Results Tree under the Thread Group for this one-user debugging run. Click Start. Select 01 Create session, check its response body, then open the sampler's request or the Debug Sampler introduced next to inspect variables. If you see a token in the JSON but no extracted variable, check that the extractor is nested directly beneath the session sampler and that the path is spelled exactly. JMeter post-processors run after the sampler in their scope; attaching the extractor to the wrong parent changes which response it reads.

Verification command: curl -s -X POST http://127.0.0.1:3100/sessions should return the nested token field. In JMeter, the stronger check is that the extractor yields sessionToken rather than MISSING_TOKEN. Add a Debug Sampler after the session request, run again, and inspect its JMeter Variables response in View Results Tree. Disable or remove the Debug Sampler before the final CLI run so it does not add a synthetic sample to results.

Step 3: Read Nested Catalog Data with JSONPath

Add a second HTTP Request named 02 List products, method GET, path /catalog. Add an HTTP Header Manager under this request with name Authorization and value Bearer ${sessionToken}. Keep it scoped to this request for now. If the variable was missing, the server will reject the literal sentinel instead of returning products, which is easier to diagnose than a silent fallback.

Run the plan again. In View Results Tree, select 02 List products. Its JSON response has an object named data, which contains a products array. Each array item has sku, name, and price fields. Use the JSON Path Tester view in View Results Tree to try this expression:

$.data.products[0].sku

The tester should show QA-BOOK. The index [0] names the first item. For an API that reorders products, select by a stable product code or extract all candidates. This is JSONPath; the JMESPath Extractor uses a different language.

Add a JSON Extractor below 02 List products with selectedSku as its variable name, $.data.products[0].sku as its expression, Match No. 1, and default MISSING_SKU. Put a Debug Sampler immediately after the catalog request to inspect selectedSku. The response checks the endpoint; the debug variable checks extraction. Fix a 401 before editing JSONPath.

Verification command: run curl -s -X POST http://127.0.0.1:3100/sessions to obtain a token, then run curl -s http://127.0.0.1:3100/catalog -H 'Authorization: Bearer YOUR_TOKEN' with that token. Expect data.products[0].sku to equal QA-BOOK. After a JMeter run, the Debug Sampler should show selectedSku=QA-BOOK. The curl response and JMeter variable check test different halves of the step.

Step 4: JMeter JSON Extractor Tutorial for Multiple Matches

A single indexed path is enough to drive this order, but a catalog often needs every candidate. Add a second JSON Extractor under 02 List products. Set variable name catalogSku, expression $.data.products[*].sku, Match No. -1, and default NO_SKUS. Keep the first extractor, because selectedSku still drives the next request. With Match No. -1, JMeter creates indexed variables such as catalogSku_1 and catalogSku_2, plus catalogSku_matchNr for the number of matches.

Names of created variables: catalogSku
JSON Path Expressions: $.data.products[*].sku
Match Numbers: -1
Default Values: NO_SKUS
Compute concatenation var: unchecked

After running one iteration, inspect the Debug Sampler. This server returns two matches, so you should see catalogSku_matchNr=2, catalogSku_1=QA-BOOK, and catalogSku_2=LOAD-KIT. Refer to the indexed values with ${catalogSku_1} and ${catalogSku_2}. Do not expect ${catalogSku} to hold the complete list when extracting all matches. If you select Compute concatenation var, JMeter also provides catalogSku_ALL with comma-separated matches. That is useful for logging, but it is not a safe replacement for an individual SKU when values themselves can contain commas.

One extractor can accept multiple semicolon-separated names, paths, match numbers, and defaults, but their counts must align. Separate extractors keep selection and all-match inspection clear here. The component reference specifies 0 for random, -1 for all, and a positive number for that positional match. It also documents the optional _ALL concatenation variable.

Verification command: curl -s http://127.0.0.1:3100/catalog -H 'Authorization: Bearer YOUR_TOKEN' should show two products when the token is valid. In JMeter, check the three debug variables and confirm the match count is 2. A response containing two products does not itself prove that Match No. -1 was configured; the indexed variables do.

Step 5: Use the Extracted SKU to Create an Order

Add 03 Create order as an HTTP Request after 02 List products. Set Method to POST, Path to /orders, and Body Data to the following exact JSON. Add an HTTP Header Manager under this request with Authorization: Bearer ${sessionToken} and Content-Type: application/json.

{"sku":"${selectedSku}","quantity":2}

JMeter substitutes ${selectedSku} before sending. The local API accepts either known catalog SKU and a positive integer quantity. If extraction failed, it receives MISSING_SKU, rejects the request with HTTP 400, and makes the chain visibly fail. This is preferable to hardcoding QA-BOOK in the order body, which would let a broken extractor go unnoticed.

Add a JSON Extractor below 03 Create order: variable orderId, JSONPath $.order.id, Match No. 1, default MISSING_ORDER_ID. Add a Response Assertion to check the response code 201, or use a JSR223 Assertion in the next step to check several conditions together. The ID is generated on each successful create, so a static expected value would be wrong. Keep the extraction on the create sampler only; a Thread Group-scoped extractor could overwrite orderId on later responses that do not contain this path.

Add a Debug Sampler immediately after create, then run the plan. The create Request tab should show a concrete SKU, and its response should contain order.id, order.sku, order.quantity, and order.state. Inspect that Debug Sampler for a fresh orderId. If you stop after inspecting the response and never check the variable, you have validated the API but not the correlation.

Verification command: use a current token from POST /sessions and run curl -i -X POST http://127.0.0.1:3100/orders -H 'Authorization: Bearer YOUR_TOKEN' -H 'Content-Type: application/json' -d '{"sku":"QA-BOOK","quantity":2}'. Expect HTTP 201 and a new order.id. The JMeter verification is a concrete request SKU and a non-sentinel orderId in the Debug Sampler.

Step 6: Read the Same Order and Assert the Handoffs

Add 04 Read order, method GET, path /orders/${orderId}. Give it an HTTP Header Manager with Authorization: Bearer ${sessionToken}. The new ID changes on every run. Compare the read response's ID and SKU with the current variables so a successful read of another order cannot pass.

Add a JSR223 Assertion under 04 Read order. Choose Groovy as the language, enable compiled-script caching if your JMeter screen offers it, and paste this code. These are JMeter's documented vars, prev, and AssertionResult bindings, not standalone Groovy globals you must define.

import groovy.json.JsonSlurper

String token = vars.get('sessionToken')
String sku = vars.get('selectedSku')
String id = vars.get('orderId')
String failure = null

if (!token || token == 'MISSING_TOKEN') {
    failure = 'Session token was not extracted'
} else if (!sku || sku == 'MISSING_SKU') {
    failure = 'Catalog SKU was not extracted'
} else if (!id || id == 'MISSING_ORDER_ID') {
    failure = 'Order ID was not extracted'
} else if (prev.getResponseCode() != '200') {
    failure = 'Read order returned HTTP ' + prev.getResponseCode()
} else {
    try {
        def data = new JsonSlurper().parseText(prev.getResponseDataAsString())
        if (data.order?.id != id) {
            failure = 'Read order ID differs from create response'
        } else if (data.order?.sku != sku) {
            failure = 'Read order SKU differs from catalog selection'
        } else if (data.order?.quantity != 2 || data.order?.state != 'created') {
            failure = 'Read order fields do not match the request'
        }
    } catch (Exception ex) {
        failure = 'Read order response is not valid JSON: ' + ex.message
    }
}
if (failure != null) {
    AssertionResult.setFailureMessage(failure)
    AssertionResult.setFailure(true)
}

The assertion checks the extraction sentinels before parsing. It then checks status before assuming a JSON order response. Finally it checks identity, selection, and requested quantity. This is more informative than a single status assertion: a server could return HTTP 200 with a different order. In a production plan, prefer targeted built-in assertions when they express the contract cleanly, and use Groovy for cross-response comparisons like these. The JSR223 Assertion documentation lists these bindings and the failure methods.

Verification command: run curl -i http://127.0.0.1:3100/orders/YOUR_ORDER_ID -H 'Authorization: Bearer YOUR_TOKEN' using the ID and token from the same session. Expect HTTP 200 and matching order.id and order.sku. Run the JMeter plan and check that 04 Read order is green with no assertion failure. Deliberately change its path to /orders/not-a-real-id once; the assertion should fail with a status message. Restore /orders/${orderId} before saving.

Step 7: Save and Run the Plan from the CLI

Remove or disable Debug Samplers and View Results Tree after the one-user inspection. Those elements are useful for development but consume memory or add diagnostic samples. Keep all four HTTP Requests and their scoped extractors and assertions. Save json-extractor-lab.jmx again. Run it from a terminal on the same machine as the local Node API:

jmeter -n -t json-extractor-lab.jmx -l json-extractor-results.jtl

If JMeter is not on PATH, substitute the full path to the installed JMeter launcher. On Windows, use jmeter.bat and a path appropriate to your shell. The -n option runs without the GUI, -t points to the saved plan, and -l writes sample results. Use a fresh results filename for each run or move the old result aside, since mixing runs makes diagnosis harder. The official CLI options document these flags.

Check the JTL file's success field for the four requests. A summary with four completed samples and zero errors is the expected outcome for one user and one loop, provided the local API remains running. Do not interpret that tiny local run as a performance benchmark. Its purpose is to prove the extraction path, variable handoff, and assertion in the same mode you would later use for load execution. Before increasing threads, decide how sessions, created orders, and cleanup should behave per user.

Verification command: jmeter -n -t json-extractor-lab.jmx -l json-extractor-results.jtl should finish with four request samples and no failures. Open the JTL as CSV or load it in a listener after the run, then inspect labels and the success column. If you see extra rows, check whether a Debug Sampler is still enabled. If the CLI cannot connect while the GUI could, confirm that the Node process and the CLI are running on the same host.

Choosing Paths, Match Numbers, and Defaults

Use a narrow path that matches the response contract. $.session.token is better for this API than $..token, because the latter can start matching an unrelated nested field when the service evolves. For arrays, $.data.products[*].sku returns every SKU while $.data.products[0].sku targets one position. A positional choice is only dependable when ordering is part of the API contract. If the selection must be based on an attribute, test an appropriate JSONPath filter in View Results Tree against a real response before saving it in the plan.

Match No. 0 is random, not first. Match No. 1 is the first result, and -1 requests all results. A positive number beyond the number of matches invokes the configured default. Set a conspicuous default that cannot be mistaken for valid business data, then assert against it before making dependent requests. Defaults help diagnosis; they are not recovery data. An empty or plausible default such as QA-BOOK can silently make a broken query look successful.

A JSON Extractor transforms response data into variables. It does not validate that the server returned the right status, that an extracted ID belongs to the current user, or that the next request used the same entity. Put assertions at those boundaries. The JSON Assertion reference covers path and expected-value checks; use it for a response-local condition. Use a JSR223 Assertion for comparisons against values captured from earlier samplers, as this plan does. For a broader assertion strategy, see JMeter assertions and listeners.

Troubleshooting

Problem: sessionToken equals MISSING_TOKEN -> Inspect the session response body. Confirm that the extractor sits under 01 Create session, uses $.session.token, and applies to the main sample. A response wrapper change requires a new path; changing Match No. will not fix an incorrect property name.

Problem: the catalog request returns 401 -> Check the resolved Authorization header in View Results Tree. It must contain Bearer followed by the current token. If you restarted the Node server, its session set was cleared; run the plan from the first request again.

Problem: the JSON Path Tester finds values but catalogSku_1 is absent -> Confirm the all-match extractor uses Match No. -1, not 1, and that it is a child of 02 List products. Also check the exact variable prefix. ${catalogSku} and ${catalogSku_1} are different lookups.

Problem: create order returns 400 -> Open its Request tab. If the body contains MISSING_SKU or literal ${selectedSku}, fix extraction or variable spelling. If the SKU is concrete, check that the body is valid JSON, that Content-Type is application/json, and that quantity is a positive integer.

Problem: read order returns 404 -> Inspect the actual URL and compare its ID with the create response. A stale orderId from an earlier run or a restarted local API cannot identify the current order. Scope the extractor under create and rerun all four samplers in order.

Problem: GUI succeeds but CLI reports failed samples -> Keep the local server running and use the same saved .jmx file. Check the CLI JTL labels and JMeter log for the first failed request. Relative file paths, different hosts, or an unsaved extractor edit can cause the two runs to diverge.

Interview Questions and Answers

In an interview, explain the chain with exact values: $.session.token feeds the Authorization header, $.data.products[0].sku feeds the order body, and $.order.id feeds the read path. Then explain how you prove identity with the final assertion. The interviewQnA entries below give model answers for match numbers, defaults, scope, and failure diagnosis.

Common Mistakes

• Putting the extractor under the Thread Group when only one sampler's response should supply a variable. That can cause later responses to overwrite a good value.
• Leaving Match No. blank and assuming it means the first match. JMeter's documented default is 0, which means random.
• Treating an extractor default as a valid substitute for a missing ID. A sentinel should force a failure, not let the plan continue unnoticed.
• Reading ${catalogSku} after Match No. -1 and overlooking the indexed variables. Inspect catalogSku_matchNr and use the numbered variables deliberately.
• Testing only the producer response. A green create sample does not show that the consumer sent the extracted value or read the same entity.
• Keeping View Results Tree enabled during a substantial load run. Use it while debugging a small plan, then disable it for CLI execution.

Conclusion

The JSON Extractor connects a response field to a later JMeter request. In this plan, three extractors capture a token, a product SKU, and an order ID; a fourth demonstrates all-match array extraction. The final read and assertion turn those values into a checked workflow rather than a collection of green HTTP statuses. Save the plan, rerun it from the CLI, and adapt each path to your own API's documented response shape.

Where To Go Next

Add a cleanup request and make each virtual user create its own data before you increase concurrency. The JMeter correlation tutorial extends the response-to-request pattern. Use JMeter CSV Data Set Config to supply independent user input, and JMeter thread groups explained to control load shape. For request validation and diagnostics, revisit JMeter assertions and listeners. If you are building a larger workflow, the API performance testing tutorial places correlation inside an end-to-end test design.

Keep the one-user plan as a regression check. When it fails, start with the earliest missing value rather than the last 404; the first broken producer usually explains every downstream error.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• API Testing with pytest and requests: Step-by-Step Tutorial
• Boundary Value Analysis With Examples (2026)
• Create Cypress Query Commands with TypeScript: Cypress Query Commands TypeScript Tutorial
• Cypress cy.wait with alias: Examples
• Equivalence partitioning with examples (2026)
• Evaluate RAG Citation Correctness with Examples