Preparing forms for cobrowsing

When an agent starts a cobrowsing session, Univerx streams a live representation of the visitor’s DOM to the agent. Form inputs are included in that stream so the agent can see what the visitor is filling in and guide them step-by-step. This is intentional and useful — but some fields should never be visible to an agent, such as passwords, payment card numbers, and other personally identifiable information (PII).

This guide applies to both integration methods — the embedded widget and the Client SDK. Masking is handled at the DOM serialization layer before any data leaves the visitor’s browser, so the same HTML attributes and CSS classes work regardless of how you have integrated Univerx.

This guide explains what is masked automatically and how to mark additional fields yourself.

How masking works

Masking intercepts a field at the serialization layer, before any data leaves the visitor’s browser. When a field is masked:

• Its current value is never captured or transmitted.
• Input and change events on that field are silently dropped — the agent cannot reconstruct the value by replaying keystrokes.
• The agent sees the field rendered normally in their view, but with a placeholder (e.g. ••••••••) instead of the real value.
• The field’s label, placeholder text, and all other attributes are still visible so the agent can understand context.

Blocking is stricter: a blocked element is excluded from the DOM snapshot entirely and the agent cannot see it at all.

Automatic masking

The SDK automatically masks the following without any extra code:

What is masked	Why
<input type="password">	Always sensitive
<input type="hidden">	Often contains CSRF tokens or session IDs
<input type="email">	Contains personal email addresses
<input type="tel">	Contains personal phone numbers
autocomplete="current-password" or "new-password"	Password managers populate these
autocomplete="cc-number", "cc-exp", "cc-csc", "credit-card"	Payment card data
name containing password, pass, pwd (on input, textarea, select)	Common naming conventions for passwords
name containing credit, card, ccv, cvv (on input, textarea, select)	Common naming conventions for card data
name containing ssn, social (on input, textarea, select)	Social security numbers
name containing csrf, xsrf, token, session, auth	Security tokens
Any value matching a 12–19 digit sequence	Credit card numbers typed into generic inputs
Any value matching an SSN pattern (e.g. 123-45-6789)	Social security numbers typed into generic inputs
Any value matching an email address	Email addresses typed into generic inputs

Note

Automatic masking is a best-effort safety net. Do not rely on it alone for fields that contain regulated or contractually sensitive data — always apply explicit masking (see below) to fields you know are sensitive.

Explicitly masking a field

Add the data-cobrowse-mask attribute or the cobrowse-mask CSS class to any input, textarea, or select element you want masked.

Using the data attribute

<!-- SSN field – agent sees ••••••••, not the real value -->
<input type="text" name="ssn" data-cobrowse-mask />

<!-- Date of birth -->
<input type="text" name="date_of_birth" data-cobrowse-mask />

<!-- A textarea with sensitive free text -->
<textarea name="medical_notes" data-cobrowse-mask></textarea>

Using a CSS class

Useful when you prefer to centralise masking through a design system or class utilities:

<input type="text" name="ssn" class="cobrowse-mask" />

Both approaches are equivalent. You can also combine them freely across your codebase.

React example

export function PersonalDetailsForm() {
  return (
    <form>
      <label>
        Full name
        <input type="text" name="full_name" />
      </label>

      {/* SSN is sensitive — mask it */}
      <label>
        Social security number
        <input type="text" name="ssn" data-cobrowse-mask />
      </label>

      {/* Date of birth is PII — mask it */}
      <label>
        Date of birth
        <input type="date" name="dob" data-cobrowse-mask />
      </label>
    </form>
  );
}

Blocking an element entirely

Use data-cobrowse-block or the cobrowse-block CSS class when you want the agent to see nothing at all — not even the field outline or label. The element and all its children are excluded from the DOM snapshot.

<!-- Agent cannot see this element at all -->
<div class="sensitive-section" data-cobrowse-block>
  <label>Account PIN</label>
  <input type="text" name="pin" />
</div>

Caution

Blocking hides context from the agent as well as the value. Prefer masking for individual inputs so the agent can still understand what the visitor is filling in. Use blocking for entire sections that are off-limits, such as embedded third-party payment iframes or confidential internal panels.

Masking vs. blocking: when to use which

Scenario	Recommended approach
Password or PIN input	Automatic — no action needed, or add data-cobrowse-mask for clarity
SSN, tax ID, date of birth	data-cobrowse-mask
Medical or legal free-text fields	data-cobrowse-mask
Entire payment form section	data-cobrowse-block
Third-party iframe (e.g. Stripe Elements)	data-cobrowse-block on the container
Internal admin notes not relevant to visitor	data-cobrowse-block

Checklist before going live

Before enabling cobrowsing in production, review every form that a visitor might interact with during a support session:

• All password and PIN inputs are masked (automatic, but verify).
• Payment card fields are masked or the payment section is blocked.
• Government-issued ID numbers (SSN, tax ID, passport) carry data-cobrowse-mask.
• Date of birth and other PII fields carry data-cobrowse-mask.
• Any third-party embedded components (payment iframes, identity verification widgets) are blocked with data-cobrowse-block.
• Free-text fields where visitors might type sensitive information are masked.

Tip

Ask your data protection officer or legal team to review which fields in your application fall under your privacy policy or relevant regulation (e.g. GDPR, HIPAA). Use that list to drive the checklist above.