This is a decision guide. It assumes you already know how to find sensitive fields in a document (the PII detection and redaction pillar covers the mechanics) and focuses on the harder question: once the scanner flags a field, which of the three controls should you apply?
The three controls, side by side
The three options sit on a spectrum of how much of the original data survives.
Redaction removes the data. The value is deleted from the HTML before the link is published. A redacted SSN is not recoverable from the page, the page source, or the DOM, because it is not there. Redaction is irreversible by design — that is the point, and also its cost: you cannot un-redact a page for the one recipient who legitimately needed the number.
PII masking obscures the data but keeps its shape. ••••1847 still tells a reader it is a four-digit-suffixed account, still sorts, still lets a support rep confirm they are looking at the right record. Masking preserves utility that redaction destroys. Masking must happen before the HTML is published, on the server side. If the full value sits in the markup and CSS or JavaScript hides it, that is not masking — that is a value one "view source" away from the reader.
Restriction leaves the data intact and controls who can open it. Password protection, a short expiry window, a tight retention setting. Nothing is destroyed; the page is simply hard to reach and does not stay reachable forever. Restriction is the right answer far more often than teams assume, because most sensitive documents go to a small audience that is already entitled to every field in them.
The four criteria that decide it
Four questions settle almost every case. Answer them in order.
1. How large is the audience? One named recipient behaves differently from a distribution list of forty. Under roughly five known people, restriction does the work. Above that, assume at least one copy leaves your control and change the page.
2. Is the recipient already entitled to the data? A customer reviewing their own contract is entitled to their own billing details; redacting them is theatre that makes the document worse. A partner looking at aggregate performance is not entitled to end-customer emails. Entitlement is the single biggest predictor of over-redaction, because it is the question nobody asks before reaching for the black rectangle.
3. What does retention require? If policy says the artifact cannot persist past a deadline, no amount of masking helps — you need an expiry window and a retention setting that deletes the underlying record. Controls on the content and controls on its lifespan answer different auditors.
4. Will it be forwarded? Not "is forwarding allowed" — will it happen. Anything a champion needs to show their CFO will be forwarded. Anything in a campaign email is already public. When forwarding is likely, the control has to live in the page, because the password will travel in the same thread as the link.
The decision table
Four artifacts, four different answers. Map yours to the closest row.
Signed customer proposal → restrict. The buyer is entitled to their own pricing, terms, and contact details. Redacting anything makes the document unusable for the thing it exists to do. Publish it intact, set a password, and give it an expiry that matches the deal cycle rather than a default 30 days — our expiry window guide walks through picking one.
Internal lead list → mask. Reps need enough to identify and contact a lead in their own territory; they do not need the whole company's personal phone numbers in a page that will sit in someone's browser history for a year. Mask phone and email to their last segments, keep names and firmographics intact.
Partner-facing dashboard → mask. The partner is entitled to aggregate performance, not to the end-customer records underneath. Masking keeps the row counts honest while removing the identities, and the page survives being forwarded to the partner's own team.
Public landing page → redact. An unbounded audience means no control over the page survives publication, so nothing sensitive can be in it. This is the one case where destroying the data is correct, and it is the case teams most often under-protect — a sample report with real customer names in it, published as a lead magnet.
Data masking vs redaction, in one line
Redaction removes the value; masking removes the value but leaves a placeholder that preserves format and utility. Choose redaction when nobody downstream needs to know the field existed. Choose masking when the reader needs to recognize a record, match a row, or confirm they are looking at the right account.
Data masking vs encryption
Encryption protects data in transit and at rest — it is why the link is served over HTTPS and why the stored record is not readable from a disk image. It is reversible by anyone holding the key, and the browser rendering your page holds one. Encryption never decides what the reader sees.
Masking decides what the reader sees. The two are complements, not alternatives: an encrypted page with unmasked SSNs shows those SSNs to whoever opens the link. If a vendor answers "is PII masked?" with "everything is encrypted," they have answered a different question.
How the controls stack
These are layers, not a menu. Apply them in order, because each one assumes the previous is done.
- Scan and treat the content first. HTMLvault's regex scanner checks generated HTML for SSNs, financial identifiers, API keys, passport numbers, addresses, names, dates of birth, emails, and phone numbers before publication — no AI tokens, no cost. Teams and Enterprise can layer an AI scan on top using their own Anthropic, OpenAI, or Google key. Redact or mask what the scan flags before the link exists.
- Restrict access second. Password-protect the link. A password on an unscanned page protects nothing once the link is forwarded with the password attached; a password on a masked page is a second wall in front of a smaller target.
- Set expiry third. Anything from an hour to never on Pro and above. Expiry converts an indefinite exposure into a bounded one.
- Set the retention window last. Expiry stops the link resolving; retention governs how long HTMLvault keeps the underlying record and analytics — configurable from auto-delete up to two years, and the setting your auditor asks about.
What these controls cannot do
Redaction does not undo a delivered page. If the link was live for six minutes with an unmasked SSN and one person opened it, that view happened. You can delete the link, but you cannot retrieve the screenshot. Analytics tell you whether anyone opened it and from where, which converts an unknown exposure into a documented one — useful for the incident report, useless as prevention.
Client-side masking is not masking. Dots rendered by CSS over a value still present in the HTML is a visual effect. Any reader who opens developer tools, saves the page, or reads the source sees the original. Masking has to modify the markup before publication.
A password is not a per-person control. One shared password means one shared secret, and you cannot revoke it for one recipient. When you need a per-person audit trail of who opened what, use recipient-specific links and read the four obligations that actually get audited before deciding a single password satisfies your policy.
The regex scanner has a known ceiling. Structured fields — SSNs, card numbers, keys, emails, phones — match reliably. Free-text disclosure in a paragraph ("the buyer mentioned her diagnosis") does not match a pattern, which is what the optional BYOK AI layer is for. A scanner is a floor under human review, not a replacement for it.
Not all PII carries the same weight. A work email and a health record are both PII and should not get the same treatment; the PII vs SPII distinction is where that line sits and why it changes the control you pick.
Running it as a default, not a decision
The framework above is a judgment call you should have to make roughly twice, after which it becomes a template. Set link defaults per content type — proposals get password plus a 30-day expiry, lead lists get masking plus a seven-day expiry, campaign pages get scanned and published with no PII at all — and the choice stops being a per-link deliberation.
If links are created from Claude, ChatGPT, Zapier, Clay, or Gemini through the REST API or MCP, encode those defaults in the call. scan_html before create_link, with password and expiry parameters set per template, means the treatment happens whether or not anyone remembered the policy that morning.
For Margo, that is the whole payoff: the partner dashboard ships at noon with account names her partner is entitled to see, end-customer records masked, a password that isn't in the same email, and a retention window Angela signed off on once rather than every quarter. Shipping fast and shipping safe stopped being a trade-off the moment the treatment became a property of the template instead of a decision she had to relitigate at 11:40.