BROWSER-BASED TABLE TOOL

Mask Sensitive CSV Data

Mask sensitive CSV data with column removal, replacement, partial masking, or consistent tokens and a separate final review.

File contents are processed locally in your browser. Refreshing or closing clears the session. The website still requests static resources.

1 Choose original files2 Confirm settings3 Review and deliver
or drop files here

Choose files, then confirm the scope

Original inputs stay in page memory. Refreshing or closing clears them; changing language does not change data.

Synthetic examples · Normal / Boundary / Error
Page memory only · Cancellable · New copies · Refreshing or closing clears data

Prepare a controlled sample for delivery

Mask Sensitive CSV Data lets you choose how specific columns should be handled before sharing a table. Available strategies include removing a column, replacing nonempty values with fixed text, retaining selected leading or trailing characters, and assigning consistent local tokens. The operation is controlled by your column choices; it is not an automatic search for every form of personal or confidential information.

Begin by deciding what the recipient actually needs. A developer testing table structure may need only synthetic or masked values, while a support investigation may need selected identifiers that preserve links between records. Retaining a city, timestamp, unusual transaction, or free-text note can still reveal identity even after a name is removed. Masking is a useful transformation, not a guarantee of complete anonymity or suitability for every disclosure.

Import and confirm the table structure

Choose CSV, TSV, or text files, paste a table, or use the current workbench data. For file inputs, select the source encoding and parsing settings, then confirm each file. Confirm parsing and configure masking builds the tables used by the masking rules. If encoding, quoting, or delimiters change, the parsed table must be rebuilt rather than reusing a result from different field boundaries.

The original source remains available locally, but original values are hidden in the masking panel by default. Reveal local original values is an explicit action. This makes it easier to work primarily from the processed preview without automatically exposing source values in every review screen. Keep in mind that column names themselves can contain sensitive information and should also be reviewed before delivery.

Choose a strategy for each sensitive column

Keep original leaves a column untouched and places it in the final untreated-column review. Drop column removes the entire field from the processed table. Fixed replacement substitutes the configured text for each nonempty selected value, which is useful when the field must exist but its contents are unnecessary. At least one output column must remain for a usable table.

Rules apply only to the columns you choose. A value appearing in an email column and again inside a note is not automatically removed from the note. Select an appropriate strategy for the note as well, or review and edit the content separately before sharing. A report that says one column was masked does not establish that the same information disappeared from every other cell.

Define partial masking in complete characters

Partial masking keeps the chosen number of leading and trailing display characters and replaces the middle with asterisks. Character boundaries follow complete Unicode grapheme clusters, so a combined accented letter or a family emoji is not cut into broken fragments. The retained counts are explicit settings rather than a hidden preset that assumes every value has the same length.

A value shorter than or equal to the total retained character count remains fully visible. The result reports how many short values were exposed so you can inspect them before delivery. For example, retaining one leading and one trailing character can hide the middle of a longer name but leave a two-character name unchanged. If that exposure is unacceptable, use a fixed replacement, token, or column removal instead.

Use consistent tokens to preserve relationships

Consistent token assigns the same token to equal original text within the chosen mapping scope and business domain. Different original values receive distinct generated tokens. Matching uses the original text exactly; it does not trim whitespace, change case, normalize email addresses, or claim that two records describe the same verified person. Those interpretation choices would require separate business rules.

Token mapping scope can be shared across selected files or separate for each file. Business domain controls whether selected columns share a mapping. Use the same domain only when equality across those fields should carry the same relationship. A customer code and a supplier code may have identical spelling while identifying unrelated entities; separate domains prevent that accidental linkage. Tokens are local to this run and are not stable identities across unrelated sessions.

Preserve empty values deliberately

Missing cells and empty strings remain empty by default under masking. They are not all assigned one entity token, because an absent email is not evidence of one shared person. A string containing spaces is still a string, and literal values such as NULL, N/A, zero, and false are not automatically considered empty.

Review the input's missing-value convention before choosing rules. If you need to standardize a particular missing marker, do so explicitly in a separate step and inspect the effect. Masking should not quietly change the semantics of a field while hiding its original values. Preserving empty distinctions in memory also helps explain why a field's masked token count may differ from its total record count.

A complete shared-email example

Suppose two files use the same columns and both contain lin@example.test. One file also contains chen@example.test. Confirm both inputs, choose a shared mapping scope, and assign the email column to the people domain with Consistent token. The repeated email receives the same generated token in both files, while the other email receives a different token. The token itself contains no original email spelling.

Remove the name column when the recipient does not need names. Review the notes column separately, because a note may repeat an email address or include identifying details. Run complete input to inspect the processed tables. Check the repeated token relationship, unchanged record counts, omitted name field, and every untouched column before enabling final delivery review.

Complete the final review after processing

The result panel lists untreated columns and the number of short values that partial masking left exposed. Review the processed grid, including free text and field names. The explicit final-review checkbox confirms that review. Run complete input again after checking it so the deliverable result corresponds to the reviewed configuration. Any input or rule change invalidates that approval and makes the old result stale.

The grid is paginated, and its search only filters the visible review view. It does not silently narrow the files in the default download. When several compatible input files participate, inspect each processed-file view. Sharing a token scope does not merge the files into one table; the result package retains separate numbered processed files so their intended relationships remain reviewable.

Keep mapping downloads separate

The default download contains processed CSV files and a count summary. It does not include the original files, source history, original-value reports, or the token mapping. Output names are generic and do not repeat potentially sensitive source filenames. Summary fields describe counts and rules without listing the original values that were replaced.

A sensitive mapping download is a separate explicit action with its own acknowledgement. That file contains original values and the tokens that replace them, so it can undo the privacy effect of tokenization if delivered alongside the sample. Keep it separate and download it only when your workflow requires it. The mapping is not uploaded or automatically persisted by the application, and refreshing the page clears the in-memory copy.

Verify export and continue safely

Verify export and show summary prepares the reviewed package and reads generated CSV back before downloading. Formula-like output text can receive explicit apostrophe protection, including values in untouched columns. The affected-cell count is shown. This protection changes the exported text and is not a promise that every spreadsheet application will handle every file safely. Review whether the recipient needs protected CSV or exact original output spelling.

Continue with the current result establishes a new workbench input containing only processed data and generic source information. The old tool's ordinary original-data view then refers to that processed boundary, not to the pre-masking file. Local undo before leaving the masking task remains available through its retained input and rule history, but those originals must not travel in an ordinary result package or downstream export.

Limitations and practical checks

The tool requires compatible schemas when applying shared rules across multiple files. It does not infer similarly named fields or reconcile different column orders for masking; align the tables first if necessary. Processing is bounded by size, records, columns, field length, and task duration. Cancel task stops the worker, and stale results cannot be delivered. Switching interface language changes labels without translating real names, notes, or other data.

For a sensitive delivery, inspect the whole downloaded package, not just a preview containing asterisks. Check the filenames, manifest or summary, data files, and any separately chosen mapping. Search for representative original identifiers where full removal was intended, and check that retained context does not reveal more than needed. Automated transformation supports this review; it cannot decide the recipient's legitimate information needs for you.

Frequently asked questions

How can I share a sample without exposing names and contact details?

Review every column, then choose removal, replacement, partial masking, or consistent tokens for the fields that need it. Check remaining free text, source information, and reports before downloading. A masked sample can still identify someone through other attributes, so do not describe it as fully anonymous merely because names were changed.

Is masking the same as complete anonymization?

No. Untreated fields, short partially masked values, and combinations of ordinary facts may still identify someone. Choose a strategy based on the recipient’s needs, review free text, and do not assume that replacing a name alone removes every possible identifying relationship.

Can two files keep matching records after masking?

Yes. Use compatible schemas, a shared scope, and the same business domain for fields that should share tokens. Equal original text then receives the same token within the run. Separate scopes or domains deliberately produce separate token relationships.

Why does the default ZIP exclude the mapping?

A mapping contains the original values and their replacements, which can reverse tokenization. The default package therefore contains processed data and a value-free count summary. Downloading the mapping requires a separate acknowledgement and should be handled as a distinct sensitive artifact.

Can another tool export my pre-masking original?

The continuation handoff creates a fresh exportable input containing only processed cells and generic source labels. Ordinary original-data views in the next tool refer to that processed input. Do not separately attach the original file or download the sensitive mapping when preparing the sample package.