> ## Documentation Index
> Fetch the complete documentation index at: https://subtext.fullstory.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Tagging Sensitive Elements for Masking and Exclusion

> Decide which elements to tag so sensitive content is masked or excluded from session capture before you deploy.

Session capture can include any DOM content by default. This guide helps you decide which elements to tag before you deploy, so the sensitive or personally identifying information (PII) they render is masked or excluded from capture. You tag elements with the [privacy classes](/docs/api/privacy-classes) (`fs-mask`, `fs-exclude`, and others) — no JavaScript API needed.

## What to tag

Scan the codebase for elements that render any of the following:

* Email addresses, phone numbers, postal addresses
* Full names, usernames, profile photos
* Payment data — card numbers, CVV, billing details
* Auth secrets — passwords, MFA codes, recovery phrases
* Government IDs — SSN, tax ID, driver's license
* Health data, financial balances, account numbers
* Free-text fields where users may paste any of the above (notes, support messages, chat)

## Mask or exclude?

Which class you reach for depends on whether the value is sensitive or the element's very existence is.

| Class        | When                                                                                                                             |
| ------------ | -------------------------------------------------------------------------------------------------------------------------------- |
| `fs-mask`    | The element's shape matters — you want to see *that* the field was filled in, just not what was typed. Default for input fields. |
| `fs-exclude` | The element's existence is sensitive — entire payment block, internal admin tools, account settings page.                        |

<Tip>
  Default to `fs-mask` for individual inputs and `fs-exclude` for whole sensitive sections.
</Tip>

## What not to tag

<Warning>
  Some sensitive UIs render in iframes that the recorder cannot see into anyway. Don't waste effort tagging the wrapper around them.
</Warning>

| UI                                                   | Tag?    | Why                                                                      |
| ---------------------------------------------------- | ------- | ------------------------------------------------------------------------ |
| Stripe Elements / Stripe Link                        | No      | Renders in a cross-origin iframe — invisible to the recorder by default. |
| Braintree hosted fields                              | No      | Cross-origin iframe.                                                     |
| Plaid Link                                           | No      | Cross-origin iframe.                                                     |
| Auth0 / Clerk / Okta hosted login                    | No      | Cross-origin iframe or full-page redirect.                               |
| Google reCAPTCHA                                     | No      | Cross-origin iframe.                                                     |
| Native HTML payment form (your own `<input>` fields) | **Yes** | Same origin — the recorder sees it.                                      |
| Custom inputs replicating card-number UX             | **Yes** | Same origin.                                                             |

If you build a payment form with native `<input>` elements, tag those inputs. If you embed Stripe Elements, leave them alone — they're already opaque.

## Process

<Steps>
  <Step title="Walk the codebase">
    Cover form inputs (`<input>`, `<textarea>`), profile and settings pages, account/billing pages, chat or messaging UIs, anywhere PII can render.
  </Step>

  <Step title="Propose each change">
    For each element, propose the file, line, and the class (`fs-mask` vs `fs-exclude`). Wait for confirmation before writing.
  </Step>

  <Step title="Insert the class">
    Add the class, then verify the markup still compiles.
  </Step>
</Steps>

<Note>
  Tagging only takes effect on new sessions captured after deploy. Sessions already recorded are not retroactively masked.
</Note>

## Verify on a real session

The static code walk catches obvious cases. To find the rest, run the privacy MCP (or `subtext privacy propose` from the CLI) against a real session URL. It returns suggested CSS selectors that the auto-configure pipeline flagged as likely PII. Review the proposals, create rules in preview scope, verify against a preview session, then promote.

See the [privacy overview](/docs/privacy/overview) for the full governance lifecycle and the [tools reference](/docs/privacy/tools-reference) for each privacy tool's parameters.