PII Data Examples: 40 Fields and What Each One Costs You

Most searches for pii data examples land on a flat alphabetical list of field names. That list tells you what PII is. It does not tell you which fields actually hurt when they leak, or where they hide in the HTML your team is about to publish. This page is built to do both: a grouped reference of real-world fields with a one-line exposure consequence for each, then the section nobody writes — where those fields end up in AI-generated markup, and how a pre-publish scan finds them there.

If you want the conceptual grounding first, start with what PII privacy is and why it matters. If you already know what you're holding and just need it out of the file, the scan-before-sharing walkthrough is the how-to. This is the reference in between.

Who this reference is for

Three roles, three different reasons to care.

• RevOps and sales leaders ship the artifacts that carry the most PII per square inch: lead lists, account exports, pipeline dashboards, proposals with a signer's details in the footer.
• Marketing ships pages that collect PII and preview pages that accidentally contain it — a campaign mock populated with real form submissions instead of dummy rows.
• IT and security own the consequence. They are the ones who get asked, six months later, which fields were in the link and who opened it.

The practical unit of risk here is a link someone forwards. Not a breach, not a hack — a Slack paste, a re-forwarded email, a deck link that outlives the deal. That framing is what makes the "exposure consequence" column below useful rather than academic.

Types of PII data, grouped by damage

PII identification gets easier when you stop sorting fields alphabetically and start sorting them by what an outsider can do with them. Four groups, roughly in ascending order of how bad a bad day gets.

Group 1: Direct identifiers

These name a specific human on their own, with no joining required.

• Full name — the anchor every other field attaches to. Alone it's low risk; combined with anything below it turns a record into a person.
• SSN or national ID number — the highest-consequence field in most datasets. Exposure consequence: identity fraud that the affected person spends years unwinding, plus mandatory breach notification in most jurisdictions.
• Passport or driver's licence number — government-issued and slow to replace. Consequence: account-opening fraud and travel-document abuse; you cannot rotate a passport number the way you rotate a password.
• Email address — both an identifier and a delivery channel. Consequence: targeted phishing against a named person at a named company, which is exactly how the next incident starts.
• Phone number — increasingly the second factor for everything. Consequence: SIM-swap and voice-phishing attempts against someone who never agreed to be in your file.
• Home address — physical-safety territory. Consequence: harassment risk, and a compliance conversation you will not enjoy.
• Date of birth — the classic joining field. Consequence: with a name, it defeats most call-centre identity checks.
• Signature image — common in proposal and contract HTML. Consequence: document forgery.
• Employee ID or payroll number — employee PII people forget is PII. Consequence: internal impersonation and HR-system probing.

Group 2: Financial and account data

Directly monetizable, which is why it moves fastest once it's out.

• Full card number (PAN) — consequence: immediate fraudulent charges and a card-scheme compliance incident.
• Card expiry and CVV — consequence: the difference between a useless number and a working one. Never store, never render.
• Bank account and routing / IBAN — consequence: payment redirection fraud, the invoice scam that actually works.
• Tax identification number — consequence: fraudulent filings against a business or individual.
• Salary or compensation figure — employee PII with social consequences as well as legal ones. Consequence: internal trust damage that no amount of remediation fixes.
• Invoice and purchase history — consequence: competitors learn what your customers pay, which is customer PII and pricing leakage in one field.
• Internal customer ID or CRM record ID — the most underrated field on this page. Consequence: a stable key that lets someone join two otherwise-harmless exports into a full profile.
• Credit score or risk band — consequence: an inference about a person you are almost certainly not licensed to publish.

Group 3: Technical identifiers

Under GDPR and similar regimes these count as personal data even though they never look like a name. This is where teams get surprised.

• IP address — consequence: location inference and cross-session linking; regulators treat it as personal data, so "it's just a log line" is not a defence.
• Device ID or advertising ID — consequence: a persistent handle that follows one person across apps.
• Cookie ID and session token — a session token is worse than an identifier: it's an active credential. Consequence: session hijacking, not just tracking.
• User agent plus screen dimensions — consequence: a browser fingerprint distinctive enough to re-identify a "de-identified" dataset.
• Account username or handle — consequence: cross-platform correlation of someone's professional and personal identities.
• API key or access token — not PII, but it travels in exactly the same places and does more immediate damage. Consequence: someone else's authenticated access to your systems. Treat it under the same scan; see preventing credential leaks in generated HTML.

Group 4: Sensitive / special-category data

Higher legal bar, higher human cost, and a category that rarely belongs in a shared link at all.

• Health condition, diagnosis, or prescription — consequence: discrimination risk and a special-category violation with penalties on a different scale from ordinary PII.
• Biometric data (fingerprint template, face embedding, voiceprint) — consequence: an identifier the person can never change.
• Precise geolocation (lat/long, not city) — consequence: a home address by inference, derived from a field labelled "coordinates."
• Union membership, religious or political affiliation — consequence: targeted discrimination; special-category in most privacy law.
• Sexual orientation or gender identity — consequence: outing someone who did not consent, with real-world safety implications.
• Race or ethnicity — consequence: discriminatory profiling, and a field that often arrives silently inside a demographic segment label.
• Criminal history or background-check result — consequence: employment discrimination exposure.
• Immigration or visa status — employee PII with the highest stakes for the individual. Consequence: harm you cannot remediate.

That's roughly forty fields once you count the sub-variants. Damage scales with joinability and irrevocability. A field you can rotate (password, session token) is recoverable. A field the person cannot change (SSN, biometric, DOB) is not.

Where PII actually hides in AI-generated HTML

Most PII reference pages skip this part. When a person or an AI assistant generates a dashboard, a proposal, or a lead-list page, the visible output is only part of the file. The rest of the markup carries fields nobody intended to publish.

• HTML comments. Generation tools leave notes: <!-- TODO: swap test row, real customer jdoe@acme.com -->. Invisible on the page, plain text in the source.
• JSON blobs in a <script> tag. The single biggest offender. A chart renders twelve visible points; the array behind it holds all 4,000 rows, including the columns you dropped from the table.
• Chart tooltips and data- attributes. Hover text often contains the record it came from — email, account ID, deal value — baked into the element as an attribute.
• Hidden table columns. A column set to display:none for layout reasons is still fully present in the DOM, and any recipient can read it with two clicks of an inspector.
• mailto: and tel: links. "Contact the account owner" resolves to a real address; a list of twenty contacts is twenty live identifiers.
• Alt text and image filenames. signature-a-pruitt-final.png is a name, a role, and a document type in one string.
• Off-screen debug output. A leftover pre block with the raw API response, parked below the fold.

PII does not have to be rendered to be published. This is the structural difference between scanning a database and scanning markup. A database scanner walks columns with known types. A markup scanner has to walk the whole document — comments, attributes, script contents, link targets — because in HTML there is no schema telling you where the data is.

How a pre-publish scan finds them

HTMLvault runs a regex-based scan across the full document before a link goes live. It reads the whole file — comments, attributes, script bodies, link targets — and flags matches in nine categories: ssn, financial, api_key, passport, address, person, dob, email, and phone. Pattern matching costs zero tokens, so it runs on every link on every plan, with no AI spend attached.

The workflow, in the order you'll actually do it:

1. Scan before you publish. Call scan_html over MCP or the REST API, or paste into the editor and let the scan run on save. You get back the category, the match, and where in the markup it sits.
2. Triage by group, not by count. Forty email hits in a mailto list is one decision. One ssn hit is an escalation. Sort by the severity ranking above, not by volume.
3. Fix at the source, not the surface. Delete the embedded JSON array; don't just hide the column. Hidden is still published.
4. Re-scan, then publish with controls. Set the expiry the content deserves, add a password if the audience is one named person, and set the data-retention window so the record does not outlive the deal.

Teams and Enterprise accounts can layer their own AI scan on top by connecting an Anthropic, OpenAI, or Google API key. That catches contextual PII a pattern can't — a paragraph naming a customer's health situation has no regex signature. You supply the key and pay for the tokens; the regex layer keeps running underneath either way.

A worked example: the lead-list dashboard

Concrete run-through. A RevOps analyst asks an AI assistant for an HTML dashboard of Q3 inbound leads: company, contact name, source channel, score. Clean brief, four visible columns.

What the generated file actually contains:

<!-- source: crm_export_full.csv (all 38 cols) -->
<script>const rows=[{"name":"...","email":"...",
"phone":"...","dob":"1984-03-11","addr":"...",
"cust_ref":"SYN-40219","score":88}, ...]</script>
<td data-owner="a.pruitt@example.com">Enterprise</td>
<td class="hidden">1984-03-11</td>

Scan result: email, phone, dob, address, and person matches — none of which appear on the rendered page. Under the ranking above, dob plus person plus address is the dangerous combination, because together they defeat identity verification at most call centres.

The fix takes about four minutes: trim the JSON to the four columns the charts use, delete the comment, drop the data-owner attribute, remove the hidden column entirely. Re-scan returns clean. Then publish with a 14-day expiry, a password for the external reviewer, and retention set so the link and its analytics age out on schedule. You still get views, unique visitors, scroll depth, and time-on-page — see tracking dashboard viewer engagement securely — without the 34 extra columns riding along.

Limits and caveats

A scan is a safety net, not a policy. Four things it will not do for you:

• Regex has both error modes. It flags a nine-digit order number as a possible SSN, and it misses a free-text sentence that names a person's medical condition. Expect to review flags rather than trust them blindly. The AI layer narrows the second gap; nothing closes it completely.
• Some fields have no pattern at all. Union membership, religious affiliation, sexual orientation, ethnicity — these arrive as ordinary prose or as an innocuous-looking segment label. They are a human review item, and the highest-consequence category on the page.
• "Internal ID" is not a safe category. Joinability is the risk, and a scanner cannot know which other export exists in someone's downloads folder.
• Scanning is not access control. A clean file shared as a forever-public link is still a clean file that anyone can read next year. Pair the scan with expiry, passwords, and retention windows — the mechanics are in HTML security controls that protect shared content.

One more thing: minimize before you scan. The cheapest way to pass a PII review is to not put the field in the file. If the dashboard needs a score and a company name, generate a dashboard with a score and a company name.

The checklist you can hand your team

Print this, paste it in the team channel, or drop it into your AI tool's project instructions so every generated artifact starts from it.

1. Name the fields in the file before you generate — visible and underlying.
2. Cut every field the reader does not need. Irrevocable identifiers (SSN, passport, DOB, biometric) do not belong in a shared link unless there is a documented reason.
3. Scan the full markup, not the rendered page. Check comments, script tags, data- attributes, hidden columns, mailto links, filenames.
4. Triage by severity group, not by hit count.
5. Fix by deletion, not by hiding.
6. Re-scan. Then set expiry, password, and retention to match the content's real shelf life.
7. Read anything a pattern can't catch — special-category prose — with human eyes.

Seven steps is a short enough list that a rep under deadline will actually run it. A RevOps lead who can hand this to their team has moved PII identification out of the "IT will catch it" bucket and into the hands of the people generating the files — before the link exists, not after it's been forwarded twice.