> For the complete documentation index, see [llms.txt](https://docs.bountysecurity.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bountysecurity.ai/creating-profiles/match-types.md).

# Match types

Choose the signal that distinguishes a meaningful result from a normal response.

In **Response → Grep** or **Request → Grep**, choose **Match Type** for each condition. This chooses what evidence to look for; the separate **Operator** column combines conditions.

## String and regex examples

Create a row with these values in the editor:

| Match Type    | Options        | Value                 | Purpose                             |
| ------------- | -------------- | --------------------- | ----------------------------------- |
| Simple String | Case sensitive | `specific diagnostic` | Find an exact literal marker.       |
| Regex         | As required    | `error code [0-9]{4}` | Find a four-digit error identifier. |

For a passive request profile, also select the request component in **Insertion point type**. Enter regexes as regex text; the application handles JSON escaping. Keep conditions consistent and test the saved profile on the intended engine.

## Time and size

For an active profile, add a **Time Delay** row, select **Greater than**, and enter `5`. This means **five seconds**, not 5000 milliseconds. **Between** uses a range such as `5-8`.

Distinguish **Content Length** (absolute size) from **Content Length Diff** (difference from the baseline). A baseline can add traffic. Use controls and repeated observations: network failures, load balancing, dynamic content and expired authentication can change these measurements.

## Status and content conditions

Use **Status Code**, **Content Type** or **URL Extension** rows when appropriate. A status alone rarely proves a vulnerability. See [grep conditions](/creating-profiles/grep-options.md) for list syntax and the Server limitation on multiple status/content-type rows.

## Out-of-band detection

Active profiles can use **Blind Host** matching with a configured interaction provider. Pro uses `{BC}` in payloads; Server converts it to `{BH}`. Entering a callback token does not establish working polling. Missing infrastructure affects coverage even when a scan displays Finished.

## Existing profiles and advanced modes

Saved profiles may use payload reflection, pre-encoded-payload reflection, response variations or invariations. These are part of the file/runtime contract, but not all are choices in the current Grep table. Preserve imported settings and verify the result before promising that a fresh table row recreates a legacy detector.

Pro's variation analysis uses Burp response attributes. Server does not implement equivalent variation/invariation behavior. Reflection by itself is an observation, not automatic XSS proof.

The numeric exported `MatchType` values are listed in the [technical file reference](/creating-profiles/field-reference.md). You select named controls in the editor; you do not enter those IDs to create a profile.