What Is PII Masking? Techniques and Examples

PII masking: the quick answer

PII masking is not one single technique.

The term describes a family of approaches used to reduce exposure while preserving enough utility for a particular workflow.

For adjacent concepts, compare data masking with tokenization and masking with data redaction.

What counts as PII?

Personally identifiable information is information that can identify a person directly or contribute to identifying them when combined with other information.

Direct identifiers

These are values that can directly point to a specific person.

Examples include:

• full name;
• personal email address;
• phone number;
• home address;
• customer account identifier;
• employee number;
• passport or government identification number.

Indirect identifiers

Other details may become identifying when combined.

Examples can include:

• age;
• job title;
• employer;
• location;
• dates associated with events;
• rare characteristics;
• organizational roles.

Context matters.

A value that looks harmless in isolation may become identifying when it appears alongside other details.

That is one reason PII protection should not be reduced to simply searching for a short fixed list of fields.

Why mask PII?

Organizations often need to use information without giving every person, system, environment, or third party access to the original personal values.

PII masking can help reduce unnecessary exposure in workflows such as:

• software development;
• application testing;
• analytics;
• technical logs;
• demonstrations;
• customer support;
• document review;
• data sharing;
• AI-assisted work.

Consider a developer who needs to test whether a customer portal correctly displays:

• names;
• email addresses;
• phone numbers;
• account numbers.

The application needs realistic data structures.

It does not necessarily need the real customers.

A masked dataset can preserve useful structure without exposing the original production values.

The same principle can apply to unstructured text, although the techniques may be different.

Static PII masking

Static masking creates a protected version of data before it is copied or used elsewhere.

For example, a production table might contain:

The development environment receives realistic data, but not the original values.

Static masking is useful when teams need durable protected copies for:

• development;
• testing;
• training environments;
• demonstrations;
• analytics.

The protected copy can remain useful without giving those environments access to the production identities.

Dynamic PII masking

Dynamic masking changes what a user sees without necessarily replacing the underlying source data.

For example:

Original:

418-555-0194

Authorized user:

418-555-0194

Restricted user:

***-***-0194

The database may still contain the original value.

The masking happens when the information is presented.

This is useful when different users or applications need different levels of visibility.

Dynamic masking is therefore different from producing a permanently transformed copy.

Partial masking

Partial masking leaves some parts of a value visible.

Examples:

alex.morgan@example.com

→

a***********@example.com

or:

7349218842

→

******8842

This approach is common when the user needs to recognize a record without seeing the complete value.

For example, a banking interface may show only the last few digits of an account number.

Partial masking preserves familiarity, but it also intentionally reveals part of the original information.

That trade-off should match the actual workflow.

Substitution

Substitution replaces a real value with a realistic alternative.

For example:

Sarah Martin

might become:

Emily Carter

while:

418-555-0194

might become:

514-555-7821

The protected values still look realistic.

This is especially useful when software needs to process or display data with the same general format as production information.

Substitution is common in:

• test datasets;
• demonstrations;
• development environments;
• training systems.

The goal is usually not to restore the original identity later.

The goal is to create useful protected data.

Shuffling

Shuffling rearranges real values across records.

Suppose a dataset contains:

A shuffled version might redistribute the cities so that the original associations no longer remain.

The values themselves may still be realistic because they came from the real dataset, but the relationships have changed.

Shuffling can be useful for structured data, but it requires care.

If too many related fields remain intact, records may still be identifiable.

Redaction

Redaction removes or obscures information.

For example:

Sarah Martin approved account 734921.

could become:

[REDACTED] approved account [REDACTED].

Redaction is appropriate when the protected version does not need the original values and they should not appear in the shared copy.

It is common for:

• public documents;
• legal disclosure;
• records;
• reports;
• PDFs;
• screenshots.

Redaction is different from a reversible token workflow.

If later restoration is required, permanent removal may reduce the usefulness of the protected content.

PII tokenization

Tokenization replaces PII with a controlled surrogate value.

For example:

Sarah Martin → [PERSON_1]

and:

sarah.martin@example.com → [EMAIL_1]

An authorized workflow can keep the relationship between the tokens and original values separately.

This can make tokenization useful when the original values should not be exposed to the system processing the protected version but may need to be restored later.

Example

Original:

Sarah Martin from Northstar Advisory asked Jordan Lee to revise the contract.

Tokenized:

[PERSON_1] from [COMPANY_1] asked [PERSON_2] to revise the contract.

The protected text still preserves useful relationships:

• [PERSON_1] and [PERSON_2] are different people;
• [PERSON_1] is associated with [COMPANY_1];
• repeated references can remain consistent.

This is different from simply replacing every sensitive value with [REDACTED].

Is PII masking the same as anonymization?

Not necessarily.

Masked data should not automatically be described as anonymous.

Some masking methods:

• preserve part of the original value;
• retain the original value elsewhere;
• allow authorized restoration;
• preserve relationships that may still contain identifying context.

Irreversible anonymization has a different goal: preventing information from being associated with an identifiable individual in a way that cannot simply be reversed through a retained mapping.

The exact legal interpretation depends on context and jurisdiction, so technical masking alone should not be treated as a guarantee of legal anonymization.

A reversible tokenized value, for example, should not automatically be called irreversibly anonymous if an authorized mapping still exists.

Explore the distinction in depth in data masking versus anonymization, or compare the broader set of data anonymization techniques.

Is PII masking the same as encryption?

No.

Encryption transforms information using cryptographic keys.

A system with the proper key can decrypt the original value.

Masking instead changes what data is exposed or used in a particular workflow.

For example:

Encryption:

Sarah Martin → encrypted ciphertext

Masking:

Sarah Martin → S***** M*****

Tokenization:

Sarah Martin → [PERSON_1]

Redaction:

Sarah Martin → [REDACTED]

These techniques can complement each other, but they solve different problems.

PII masking in databases

Database masking is one of the most established uses of PII protection.

Structured databases make sensitive fields easy to identify:

• first_name
• last_name
• email
• phone
• address
• account_id

A masking system can apply rules to those columns before data reaches development or testing environments.

For example:

This works well because the location and type of each sensitive value are known in advance.

Free text is more complicated.

PII masking in application logs

Logs often contain unexpected personal information.

A log entry could accidentally include:

Password reset requested by sarah@example.com from account 734921.

If those logs are:

• stored for long periods;
• sent to monitoring platforms;
• accessed by many engineers;
• copied into support tickets;

PII exposure can spread far beyond the original application.

A protected version might instead be:

Password reset requested by [EMAIL_1] from account [ACCOUNT_1].

Masking logs can reduce unnecessary exposure while retaining enough structure for debugging.

But the method needs to preserve the operational details engineers actually need.

PII masking in APIs

APIs can also expose more information than a downstream service requires.

Suppose a service only needs to know whether an account is valid.

Sending:

{
  "name": "Sarah Martin",
  "email": "sarah@example.com",
  "account": "734921",
  "status": "active"
}

may expose more PII than necessary.

A privacy-conscious workflow might minimize, mask, or tokenize fields before the request leaves the trusted environment.

The exact approach depends on whether the receiving system needs:

• realistic values;
• stable identifiers;
• partial information;
• no personal data at all.

Masking should follow the purpose of the data transfer rather than simply transforming everything in the same way.

PII masking in documents and free text

Unstructured text creates a different challenge.

Sensitive information may appear anywhere in:

• emails;
• contracts;
• HR notes;
• research material;
• support tickets;
• reports;
• meeting notes;
• legal correspondence;
• technical documents.

There is no fixed email column or customer_name field.

Consider:

Sarah Martin from Northstar Advisory called from 418-555-0194 regarding account 734921.

A contextual protected version could become:

[PERSON_1] from [COMPANY_1] called from [PHONE_1] regarding account [ACCOUNT_1].

The sentence remains understandable.

That matters when the protected text still needs to be:

• summarized;
• rewritten;
• translated;
• classified;
• reviewed;
• analyzed.

PII masking before ChatGPT and other AI services

Generative AI introduces another place where sensitive professional text can be unnecessarily exposed.

A user may want help with:

• rewriting an email;
• summarizing a report;
• reviewing a contract;
• translating a message;
• drafting a response;
• extracting action items.

The AI may need the meaning of the text.

It often does not need the real identity of every person, organization, account, phone number, or email address.

That creates an opportunity to protect PII before the text reaches the AI service.

Example workflow

1. Original text

Sarah Martin from Northstar Advisory asked us to email the revised agreement to sarah.martin@example.com.

2. Protected locally

[PERSON_1] from [COMPANY_1] asked us to email the revised agreement to [EMAIL_1].

3. AI output

Please confirm that [PERSON_1] will receive the revised agreement at [EMAIL_1].

4. Restored locally

The authorized workflow restores the original values after the AI task.

The AI can work with the protected text without requiring the real values for that particular task.

This is the type of workflow Layrin is designed around.

Layrin uses reversible local tokenization for unstructured professional text. Sensitive originals and token mappings remain local, the user reviews the protected text, and only the reviewed protected version may be used with the selected AI service.

This should not be confused with traditional database masking or with permanent anonymization.

PII masking and context preservation

One of the most important decisions in PII masking is how much context to preserve.

Compare these two protected versions.

Generic redaction

[REDACTED] from [REDACTED] asked [REDACTED] to call [REDACTED].

Contextual placeholders

[PERSON_1] from [COMPANY_1] asked [PERSON_2] to call [PHONE_1].

The second version reveals more about the structure of the sentence without exposing the original values.

For some workflows, that extra semantic context is useful.

For others, even the category itself may reveal too much.

There is no universal masking level that is correct for every use case.

PII masking techniques compared

The important point is to select the method based on what happens after protection.

How to choose a PII masking method

Is the text going to an AI service?

Ask whether the AI actually needs the original PII.

If not, masking, redaction, or tokenization should happen before the external AI task where appropriate.

PII masking best practices

Common PII masking mistakes

Masking only obvious identifiers

Names and emails are important, but sensitive information can also appear in:

• account identifiers;
• internal IDs;
• addresses;
• health information;
• financial references;
• employee data;
• unusual contextual details.

Treating every value the same way

A phone number, a person’s name, and a confidential project name may need different protection.

Using permanent redaction when restoration is required

If a workflow later needs the original identities, replacing everything permanently with [REDACTED] can create unnecessary friction.

Preserving too much information

Partial masking is useful only when the visible portion serves a legitimate purpose.

Assuming automation catches everything

No sensitive-data detector should be treated as infallible.

Review remains important, especially for unstructured text.

Frequently asked questions