> ## Documentation Index
> Fetch the complete documentation index at: https://docs.os.default.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Privacy & Data Handling
> What the Pixel never captures, where it skips tracking by default, and how consent gating works.
## Fields never captured
Regardless of what a form asks for, the Pixel drops the value of any field whose **name**
matches a sensitive pattern. The full list:
`password`, `secret`, `token`, `key`, `auth`, `credential`, `ssn`, `credit card`, `cvv`,
`cvc`
Matching is case-insensitive and substring-based, so `user_password` and `apiToken` are
both caught. Beyond that:
* **File uploads are never sent.** File inputs are skipped entirely — the Pixel records
nothing about the file, not even its name.
* **Password-typed inputs are excluded from form detection**, so they never become part
of a form's mapped structure.
* **CMS password gates are ignored.** A form that is exactly a Webflow-style gate
(`page` + `pass` + `path`) is recognized as a gate rather than a lead form and skipped.
On submission, the filter matches on the field's **name**, not its input type. A
password input named something outside the list above — `pwd`, for example — is not
recognized as sensitive. Name your sensitive fields to match the patterns above, or
exclude the form with `data-default-ignore`.
## Turning capture off
You have three levels of control, from broadest to narrowest.
**Paths excluded by default.** The Pixel doesn't capture anything on pages whose path
contains `/login`, `/signin`, `/account`, `/checkout`, `/oauth`, or `/admin/`. Matching is
a case-insensitive substring test on the path, so `/my-account/settings` is excluded too.
Note that `/admin/` needs the trailing slash — a page at exactly `/admin` is *not*
excluded.
**A whole page.** Add this to the page's ``:
```html theme={null}
```
**A single form or region.** Add `data-default-ignore` to a form, or to any element that
contains it. The Pixel skips submissions, interactions, and detection for anything inside:
```html theme={null}
```
## Consent Gating
The Pixel respects visitor consent choices for two categories, and gates the
corresponding tracking behavior accordingly:
| Category | What it gates |
| ----------- | ------------------------------------------------------------------------------------------------------------------ |
| `analytics` | The stored identity that lets Default recognize the same visitor across visits, plus pageview and session tracking |
| `marketing` | Reveal — de-anonymizing visitors who haven't submitted a form |
**Form capture is never gated.** Submitting a form is itself an affirmative visitor action,
so submissions are always captured, regardless of consent state.
Neither is **form discovery** — the background scan that finds which forms are on a page.
Form capture can't work without it: a form Default hasn't discovered can't be approved, so
it can never capture anything. The scan reads the form's own structure, not the visitor.
### Default behavior
Out of the box, both categories are **allowed** — this is an opt-out model, not opt-in.
Tracking runs normally until a visitor withholds consent through your site's own consent
tooling.
The Pixel doesn't ship a consent banner or detect third-party consent tools (OneTrust,
Cookiebot, and similar) automatically. If you need visitors to be asked before
tracking runs, your own banner is responsible for asking and for telling the Pixel the
answer — see [Wiring up your consent banner](#wiring-up-your-consent-banner) below.
### What happens when consent is withheld
* **Analytics withdrawn:** any identity already stored is cleared immediately, and no
further identity is written to *either* cookies or `sessionStorage` — browser session
storage is non-exempt storage too, so it isn't used as a fallback. Pageview and session
tracking stop. The visitor is still tracked for the current page in memory (so a
single-session experience like the scheduler handoff keeps working), but nothing durable
is written, and that in-memory state is gone once the page unloads.
* **Marketing withdrawn:** Reveal won't load going forward. If it had already loaded
earlier in the session before consent was withdrawn, that can't be undone retroactively
— the setting only affects loads from that point on.
A grant made later is picked up without a page reload. Marketing consent loads Reveal on
the spot, or — if the visitor is on a page where tracking is excluded, such as `/checkout`
— on the next eligible page they visit.
### Wiring up your consent banner
Have your consent banner call `setConsent` once the visitor makes a choice. Which call to
use depends on which script you've installed:
```js theme={null}
// If you installed the Pixel tracker snippet
window.__defaultPixel__.setConsent({ analytics: false, marketing: false });
// If you're using the SDK
DefaultPixelSDK.setConsent({ analytics: false, marketing: false });
```
You can pass either or both keys — omitted keys keep their current value. Calling
`window.__defaultPixel__.setConsent` is safe even immediately on page load, before the
async tracker script has finished loading: calls are queued and replayed automatically
once it's ready.
The visitor's choice is remembered (in a first-party cookie) so it persists across
visits — you don't need to re-collect it on every page load once your banner has made
the call.
Marketing consent only has an effect where Reveal actually loads — the tracker snippet.
On a page that loads only the standalone SDK (`sdk.js`) without the tracker, there's no
Reveal to gate, so `setConsent({ marketing: false })` there is accepted but has nothing
to do. Analytics consent applies everywhere.