In JMeter's Regular Expression Extractor, what does a Template value of $1$ refer to?
answer
- Not the pattern field itself
- Assembles what JMeter finally stores
- Digits wrapped in dollar signs
- Counting follows the pattern's parentheses
basics
~20 sTemplate $1$ inserts the text captured by the first parenthesised group of the Regular Expression field. JMeter builds the stored value from the Template, so $0$ means the whole match and $1$ the first group.
solid answer
~50 sJMeter's Regular Expression Extractor never stores the raw match directly. It applies the **Regular Expression** field to the selected **Field to check**, then assembles the value from the **Template** field and writes that string to the variable named in **Name of created variable**. Inside Template, `$1$` is a placeholder for capturing group 1 of the pattern, `$2$` for group 2, and `$0$` for the whole span the pattern matched. Anything outside those placeholders is copied through literally, so `Bearer $1$` yields the group with a prefix. Because of this, the pattern normally needs at least one pair of parentheses unless the Template is `$0$`. To lift a CSRF token from a hidden form field you would set the pattern to `name="_csrf" value="([^"]+)"` and the Template to `$1$`, so the variable holds the token alone and not the surrounding markup.
go deeper
Recall that Template is a separate required field from the pattern, and that $1$ means the first parenthesised group while $0$ means the entire match.
Explain that JMeter parses Template for $digits$ and copies everything else through literally, and name the _g0, _g1 and _g variables written alongside the reference variable.
Show when you reach for the group variables instead of a second extractor, and note that a miss removes _g0, _g1 and _g while leaving the reference variable at its Default Value.
Own the convention: pick one Template shape and one reference-name scheme across the suite so extracted values are greppable, and decide whether extra groups belong in one element or several.
## What the Template field is for The **Regular Expression Extractor** is a post-processor. After each sampler in its scope it takes the text selected by the **Field to check** radio group (Body, Body (unescaped), Body as a Document, Request Headers, Response Headers, URL, Response Code or Response Message), applies the pattern in the **Regular Expression** field, and then builds the value it stores from the **Template** field. Only the assembled Template string reaches the variable named in **Name of created variable** — the match itself is an intermediate result. This indirection is the part juniors miss. Getting the pattern right is not enough; if Template is blank the extractor happily stores an empty string on a perfect match. ## The `$n$` placeholder syntax JMeter scans the Template with the fixed pattern `\$(\d+)\$`. Every `$digits$` run becomes a reference to a capturing group; every other character is copied through verbatim. | Template | What lands in the variable | |---|---| | `$0$` | the whole span the regular expression matched | | `$1$` | the text of the first parenthesised group | | `$2$` | the text of the second parenthesised group | | `token=$1$` | the literal `token=` followed by group 1 | | `$1$:$2$` | groups 1 and 2 joined by a colon | Group numbering follows the opening parentheses of the pattern from left to right, so `$1$` is always the first `(` you wrote. The JMeter GUI spells the rule out on the field label itself: *Template ($i$ where i is capturing group number, starts at 1)*. ## Why the pattern usually needs parentheses The component reference states the requirement plainly: the Regular Expression field must contain at least one set of parentheses to capture a portion of the string, **unless** you use group `$0$`. A pattern with no groups plus a Template of `$1$` is the classic beginner failure — the extractor cannot resolve the placeholder, and you get the Default Value or nothing at all. ## The group variables JMeter writes alongside With a non-negative **Match No.** and a successful match, an extractor whose reference name is `csrfToken` leaves four kinds of variable behind: - `csrfToken` — the assembled Template value, the one you actually reference downstream; - `csrfToken_g0` — the whole match, the same thing `$0$` would have produced; - `csrfToken_g1`, `csrfToken_g2`, … — one variable per capturing group; - `csrfToken_g` — the number of groups in the pattern, **excluding** group 0. So the groups are available even when the Template only uses one of them. That is useful when you want the token in one variable and, say, the field name in another without adding a second extractor — you read `csrfToken_g1` and `csrfToken_g2` directly. ## What happens when nothing matches On a miss with a non-negative Match No., JMeter sets the reference variable to the **Default Value** if one is configured, and then removes the group variables: `csrfToken_g0`, `csrfToken_g1` and `csrfToken_g` all disappear. That asymmetry is deliberate — a stale group variable next to a fresh reference variable would be far more confusing than none at all. ## A worked capture Take a login form that carries its anti-forgery token in a hidden input: ```html <input type="hidden" name="_csrf" value="9f2c1e7a-4b0d-4d2e-8a11-6c3b5d9e0f44"/> ``` Set **Regular Expression** to `name="_csrf" value="([^"]+)"`, **Template** to `$1$`, **Name of created variable** to `csrfToken` and **Match No.** to `1`. The parentheses wrap only the token, so `$1$` yields `9f2c1e7a-4b0d-4d2e-8a11-6c3b5d9e0f44` and the POST that follows can reference `${csrfToken}` directly. Change the Template to `$0$` and the same match instead stores `name="_csrf" value="9f2c1e7a-4b0d-4d2e-8a11-6c3b5d9e0f44"`, markup and all, which the server will reject. That single character is the whole reason the Template field exists as a field of its own rather than being implied by the pattern. ## Template versus the other fields Template answers *what to build from the match*. It is independent of the three fields around it, and interviewers probe whether you keep them apart: - **Field to check** decides *which text* is searched; - **Match No.** decides *which occurrence* is taken; - **Default Value** decides what is stored when nothing matches; - **Template** decides what the stored string looks like once an occurrence is chosen. ## Mistakes that cost interview points 1. Writing the Template as `$1` or `\1`. JMeter uses **dollar signs on both sides**; sed and Perl replacement syntax does not work here. 2. Treating Template as a second pattern. It is a plain string with `$n$` holes in it, nothing more. 3. Wrapping the pattern in slashes, as `/name="_csrf"/`. JMeter does not strip delimiters, so the slashes become part of what must match. 4. Capturing the surrounding markup by using `$0$` when you only wanted the value — the request then posts `value="abc"` instead of `abc`. 5. Forgetting that the placeholder count is independent of **Match No.**; `$1$` selects a *group*, Match No. selects an *occurrence*.
- Your pattern has two groups. How would you get one variable holding both, separated by a colon?Set the Template field to `$1$:$2$`. JMeter substitutes each `$n$` placeholder and copies the colon through literally, so the variable receives the two captures joined. The individual groups remain available as `_g1` and `_g2` regardless of what the Template does.
- What does JMeter do with the other capturing groups when the Template only references one of them?It still writes them. Every group is stored as `refName_gN` with `refName_g0` holding the whole match, plus `refName_g` holding the group count excluding group 0. You can read those directly without adding a second extractor.
- What happens if the Regular Expression field contains no parentheses at all?A Template of `$1$` has nothing to resolve, so the extraction effectively fails and the variable falls back to the Default Value. The component reference requires at least one pair of parentheses unless the Template is `$0$`, which refers to the whole match.
saying these in an interview costs you the question
- Says the Template uses $1 or backslash-1 like sed
- Thinks the Template is a second regular expression
- Claims JMeter always stores the whole match regardless of Template
- Cannot say which variable the captured value lands in
- Confuses the Template field with the Default Value field