In Playwright, what is the difference between page.getByText('Open') and page.getByText('Open', { exact: true })?

## What the default match does `page.getByText('Open')` builds a locator over every element whose text **contains** the argument, compared **case-insensitively**. On an issue tracker whose board header reads `Open issues`, all of `getByText('Open')`, `getByText('open')` and even `getByText('pen iss')` resolve to that heading. The default is deliberately forgiving because visible copy belongs to designers, not to test authors: a chip may be uppercased by CSS while the DOM still holds mixed case, and a substring survives copy edits that a whole-string match would not. Before any comparison happens, Playwright **normalizes whitespace** in the element's text. Runs of spaces and tabs collapse to a single space, line breaks become spaces, and leading and trailing whitespace is dropped. A template that renders a heading indented across three lines is therefore compared as the single line `Open issues`, and `getByText('Open issues')` matches it even though the raw DOM text is nothing like that string. ## What `exact: true` changes The `exact` option flips **two** switches at once, and candidates usually remember only the first: 1. The match becomes **whole-string** — the element's normalized text must equal the argument, not merely contain it. 2. The match becomes **case-sensitive** — `getByText('open', { exact: true })` no longer matches `Open`. What `exact` does **not** turn off is whitespace normalization. The multi-line heading above still matches `getByText('Open issues', { exact: true })`, because normalization runs first and the comparison sees `Open issues` on both sides. That is the most common surprise here: people reach for `exact` expecting a byte-for-byte comparison against raw markup and get a normalized one instead. ## Side by side | Element text | `getByText('Open')` | `getByText('Open', { exact: true })` | |---|---|---| | `Open` | matches | matches | | `Open issues` | matches | no match, extra text | | `OPEN` | matches, case ignored | no match, wrong case | | `Open` padded with newlines | matches | matches, whitespace normalized | | `Reopened` | matches, substring | no match | The last row is the practical reason to reach for `exact`. On a board where a filter chip reads `Open` and an activity entry reads `Reopened`, the loose default matches both, and a locator that resolves to two elements cannot be clicked — Playwright refuses ambiguous locators for actions. ## The same option on the sibling queries `exact` is not special to `getByText`. `page.getByLabel`, `page.getByPlaceholder`, `page.getByAltText` and `page.getByTitle` all accept the same `{ exact }` option with the same meaning: case-insensitive substring by default, case-sensitive whole string when set. `page.getByTestId` is the exception — it has no `exact` option because it always compares the whole test id, case-sensitively. - Keep the **default** when the copy is long and only a fragment of it is stable, such as a comment body or a toast message. - Set **`exact: true`** when the target string is a prefix or substring of neighbouring copy, such as `Open` beside `Reopened`, or `Done` beside `Done today`. - Pass a **RegExp** when neither fits — for text with an embedded count or date. `exact` is ignored for a RegExp, and a RegExp is case-sensitive unless you add the `i` flag yourself. - Remember that `exact` narrows **what text counts**, never **which elements are searched**; every element on the page is still a candidate. ## Where the option stops helping Two failures look like an `exact` problem and are not. The first is a *nesting* question: when several nested elements all contain the string, `getByText` keeps only the innermost one whose own text matches, so an outer card is not returned alongside its inner span. Tightening `exact` does nothing about ancestors, because they were never returned. The second is *repetition*: on a board where every card carries a `Comments` heading, no amount of exactness makes one of them unique. That is a scoping problem, solved by narrowing the search root to one card first and then applying the text query inside it. ## A rule of thumb Write the loose form first, run it, and let the failure tell you what to tighten. If it resolves to zero elements, your string is not in the DOM as rendered — check for a non-breaking space, an ellipsis character, or copy split across elements. If it resolves to several, decide whether the fix is `exact: true` (you matched too much text) or scoping (you matched the right text in too many places). Choosing between those two is the actual skill; `exact` is only half of the toolkit.