> 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/grep-options.md).

# Grep conditions, scope and filters

Build readable matching conditions with table rows, operators and scope.

Configure matching in the graphical **Grep** table. Active and passive-response profiles use the **Response** tab; passive-request profiles use **Request**. Click **Add**, edit the cells, and use the Enabled checkbox to include or exclude each condition.

## Table columns

| Column               | What to choose or enter                                           |
| -------------------- | ----------------------------------------------------------------- |
| Enabled              | Whether the condition participates.                               |
| Operator             | Leave the first row empty; choose how later rows combine.         |
| Match Type           | The kind of observation, such as Simple String or Regex.          |
| Insertion point type | Passive request only: the request component to inspect.           |
| Options              | An option appropriate to the selected match type.                 |
| Value                | The literal text, regex, code, threshold or other expected value. |

Type the regex directly into **Value**, for example `\d{4}`. Pro generates the JSON escaping when saving. Do not type an entire serialized grep row into that cell.

**Paste** and **Load File** can populate the table from existing grep lists. Review the resulting columns and enabled states before saving. **Remove** deletes selected rows and **Clear** empties the table.

## Operators

Later rows offer **AND**, **AND NOT**, **OR**, **OR NOT**. OR separates AND groups; there is no parenthesis editor. For example, `A AND B OR C AND D` groups as `(A AND B) OR (C AND D)`. Disabled rows do not participate.

These operators belong to profiles. Pro's Rules editor has a separate operator system and [different current limitations](/burp-bounty-pro-rules/reference.md).

## Match types and options

| Match Type          | Enter in Value / choose in Options                                    |
| ------------------- | --------------------------------------------------------------------- |
| Simple String       | A distinctive literal string.                                         |
| Regex               | The regex itself, without JSON quotes or escaping.                    |
| Blind Host          | An interaction condition with a configured provider; active profiles. |
| Status Code         | Codes separated by `;`, such as `200;201`.                            |
| Time Delay          | Seconds; choose Between, Greater than or Less than. Active profiles.  |
| Content Type        | Values such as `text/html;application/json`.                          |
| Content Length      | Absolute size with the applicable numeric comparison.                 |
| Content Length Diff | Difference from a baseline response.                                  |
| URL Extension       | Extension values, such as `.php;.jsp`.                                |

Available choices depend on the editor. The passive-request table offers Simple String and Regex, while the active and passive-response tables offer their respective additional types.

For text/regex rows, Options includes **Case sensitive** and, in response editors, **Only in Headers** and **Not in Headers**. This is a single-choice cell. Do not describe Not in Headers as a separate Only in Body control or assume it combines with Case sensitive in the same cell.

## Header/body scope and imported settings

Check scope with positive and near-miss fixtures in the engine that will execute the profile. In particular, test header-like text in the body when a condition should inspect only headers.

Exported profiles can also retain legacy whole-profile/step settings `OnlyHTTP`, `ExcludeHTTP`, `CaseSensitive` and `NotResponse`. The current response editor concentrates its visible matching controls in the table; those legacy fields are not all separate visible controls. Row options and saved legacy flags do not have a universal Java/Go equivalence guarantee. See [compatibility](/creating-profiles/compatibility.md) before reusing such a profile on Server.

## Passive request locations

Choose **Insertion point type** deliberately: All request, All parameters name, All parameters value, All HTTP headers value, or a specific component such as **Param url name** versus **Param url value**.

The menu also offers body, cookie, JSON, XML, XML attribute and multipart attribute names/values; URL path folder/filename; entire-body variants; and specific HTTP headers. A name/value pair here describes separate menu choices. A name detector should not silently become a whole-request substring search.

## Additional conditions

Add a row with Status Code, Content Type or URL Extension when the check needs that condition. In Server's converted active steps, typed Status Code/Content Type rows become preconditions and the **last enabled row of each type wins**. Use a single row with the intended value list rather than assuming two status rows form a portable OR expression.

Response conditions need a response to evaluate. They do not guarantee that no active request will be sent first. Verify which original or mutated response supplies each condition.

## Reading an exported file

Pro serializes the visible columns as five fields for active/passive-response rows and six for passive-request rows. The final field can contain commas. Those storage details belong to the [exported field reference](/creating-profiles/field-reference.md); the editor assembles them automatically.