How to redact sensitive columns before a screenshot or demo
- Step 1Decide what must be hidden before you capture anything — Identify the columns that can't appear on screen: names, emails, account numbers, internal notes. Decide per column whether to blank it (redact), remove it (drop), or fake-but-shaped it (mask/hash). Crucially, do this before you screenshot — a capture of the raw file is already a leak.
- Step 2Drop the CSV onto the anonymizer above — It parses in your browser — nothing is uploaded. Auto-detect pre-fills hash rules for recognised PII headers, which you can switch to redact or drop depending on how visible you want the censorship to be.
- Step 3Choose redact for an obviously-censored look — Add a rule per sensitive column with strategy redact. Every value becomes
[REDACTED], which reads clearly as 'intentionally hidden' in a screenshot or ticket — better than a blank cell that looks like missing data. - Step 4Choose drop for columns that shouldn't appear at all — For a column that has no business being on screen (internal margins, home address), use drop so it's removed from the header and every row. It can't leak from a screenshot if it isn't in the file.
- Step 5Choose mask or hash when the demo must look real — For a sales demo where the screen should look like live data, use mask to keep a plausible shape, or hash if two visible rows need to obviously share a key. Reserve these for when realism matters; otherwise redact/drop are safer.
- Step 6Run it, verify the preview, then capture from the scrubbed file — Click Anonymize CSV and check the first-10-row preview — confirm every sensitive column is hidden. Download
<name>.anon.csvand take your screenshot, screen-share, or attach from THAT file. Never from the original.
Best strategy by where it'll be seen
Pick based on visibility and whether the demo needs to look real.
| Destination | Recommended strategy | Why |
|---|---|---|
| Jira/GitHub ticket screenshot | redact | Obvious censorship reads clearly; no doubt a value was hidden on purpose |
| Bug-report CSV attachment | drop or redact | Vendor doesn't need the PII; drop removes it, redact keeps column shape |
| Live sales demo / screen-share | mask or hash | Screen looks like real data without exposing real values |
| Public docs / blog example | drop | Safest — sensitive columns aren't in the published file at all |
| Internal demo where joins must show | hash | Two related rows visibly share a token; raw value still hidden |
The five strategies at a glance
Behaviour taken from the tool. value is the original cell.
| Strategy | On-screen result | Keeps column? |
|---|---|---|
| redact | [REDACTED] in every cell | Yes |
| drop | Column gone entirely | No |
| mask | Front/back chars kept, middle starred (****1234) | Yes |
| hash | 16-char hex token (stable per value) | Yes |
| sequential | id-1, id-2… by row position | Yes |
Tier limits
Browser-side CSV limits. The CSV Anonymizer is Pro.
| Limit | Free | Pro |
|---|---|---|
| Max file size | 2 MB | 100 MB |
| Max rows | 500 | 100,000 |
| Batch files | 2 | 10 |
Cookbook
Quick recipes for scrubbing a file before it goes on screen or into a ticket.
Redact name + email for a Jira screenshot
ExampleA bug repro needs the row visible but the PII obviously censored. Redact blanks the values to [REDACTED] so the screenshot clearly shows intentional hiding.
Input: name,email,error_code Jane Doe,jane@acme.com,E_TIMEOUT Bob Lee,bob@globex.com,E_AUTH Rules: name → redact; email → redact Output: name,email,error_code [REDACTED],[REDACTED],E_TIMEOUT [REDACTED],[REDACTED],E_AUTH → error_code stays for the repro; PII is visibly censored.
Drop the column the vendor shouldn't see at all
ExampleA bug-report CSV for a vendor includes an internal margin column. Drop removes it so it can't leak from the attachment.
Input: order_id,amount,_internal_margin ORD-5,42.00,11.20 ORD-6,18.00,5.10 Rule: _internal_margin → drop Output: order_id,amount ORD-5,42.00 ORD-6,18.00 → margin column gone from the file you attach.
Mask for a live sales demo that must look real
ExampleOn a screen-share the audience should see realistic-looking customer rows, not [REDACTED]. Mask keeps a plausible shape.
Input:
customer,phone
Jane Doe,+15551234567
Rules: customer → mask (keepStart 1, keepEnd 1)
phone → mask (keepStart 0, keepEnd 4)
Output:
customer,phone
J******e,***********4567
→ looks like real data on screen; values are hidden.Hash so two rows visibly relate in the demo
ExampleAn internal demo needs to show that two orders belong to the same (hidden) customer. Hash makes the shared customer token identical on both rows.
Input: order_id,customer_email ORD-5,jane@acme.com ORD-6,jane@acme.com ORD-7,bob@globex.com Rule: customer_email → hash (salt: demo) Output: order_id,customer_email ORD-5,a3f10b9c4e7d2118 ORD-6,a3f10b9c4e7d2118 ORD-7,7c2e9f04b1a83dd6 → ORD-5 and ORD-6 visibly share a customer; real email hidden.
Sequential ids for a clean public example
ExampleFor a blog/docs example, real account refs are noise. Sequential gives tidy id-1, id-2 labels. (It doesn't dedupe, so use it only where each row is just an example.)
Input: account_ref,event ACME-7781,login GLBX-2210,export Rule: account_ref → sequential Output: account_ref,event id-1,login id-2,export → tidy, publishable example rows.
Errors and edge cases
Real errors and silent failures sourced from each platform's own documentation. Match the wording to the row, fix what the row says to fix.
A screenshot of the original file is still a leak
Common mistakeThe most important caveat: anonymize FIRST, then capture. If you screenshot, screen-share, or copy-paste from the original file and only redact afterwards, the real data has already been exposed. Always run the tool, download the .anon.csv, and capture exclusively from that scrubbed file.
Redact keeps the column; viewers see it exists
Behaviour to knowRedact blanks values to [REDACTED] but the column header stays. If even the existence of the column is sensitive (e.g. a medical_condition header), use drop instead so the column name doesn't appear on screen either.
Mask of a short value reveals nothing — or everything
Behaviour to knowIf keepStart + keepEnd is at least the value's length, mask returns all stars (good — fully hidden). But if you set keep counts too high relative to short values you intended to partly hide, you can accidentally show most of a short value. For demos, prefer redact for guaranteed full hiding; use mask only where a tail genuinely needs to show.
Adding a rule disables auto-detect
Behaviour to knowAuto-detect runs only with zero explicit rules. After you add your first redact/drop rule, auto-detect stops, so any PII column you assumed was being auto-hidden will appear in plaintext in the scrubbed file — and in your screenshot. After adding any rule, add explicit rules for every sensitive column and confirm via the preview before capturing.
Hash tokens still leak distribution on screen
Behaviour to knowHashing a column shows identical tokens for identical values, so a screenshot reveals how many rows share each value even though the value is hidden. Usually fine, but if the grouping itself is sensitive on screen, use redact or drop instead of hash.
Sequential ids don't survive sorting or re-runs
Behaviour to knowSequential numbers by current row position, so if you later sort the file or re-run on a different row order, the ids change, and identical real values get different ids. For a static example that's fine; don't rely on the ids meaning anything beyond 'row N of this file'.
Free tier blocks the file
BlockedThis is a Pro tool; free CSV limits are 2 MB / 500 rows. For a quick screenshot you rarely need the whole file — take just the rows you need with csv-row-limiter first, then redact that small slice. Smaller files also make a cleaner screenshot.
Wrong header name means a sensitive column stays visible
Silent missRules match the exact header text. If a rule targets email but the column is Email Address, nothing is redacted and the real data ends up in your screenshot. Always pick the column from the dropdown (populated from the file) and check the preview shows it hidden before you capture.
Values hidden in unredacted columns
Common mistakePII can hide in columns you didn't think of — a subject line, a url with an email query param, a free-text comment. The tool only touches columns you rule on. Scan every column in the preview before capturing; redact or drop any that contains identifying text, not just the obvious ones.
Frequently asked questions
What's the quickest way to censor a CSV for a screenshot?
Drop the file onto the tool, add a redact rule for each sensitive column, run, and screenshot from the downloaded .anon.csv. Redact replaces every value with [REDACTED], which reads clearly as intentional censorship. If a column shouldn't appear at all, use drop instead so it's removed entirely.
Should I use redact or drop?
Redact when you want the column to stay visible but its values blanked — useful when the column's presence is part of the context (e.g. showing that an email field exists in a bug). Drop when even the column header is sensitive or simply shouldn't be on screen. Drop is the safer default for anything that doesn't need to appear.
Can I make the demo still look like real data?
Yes — use mask to keep a plausible shape (j****n, ****1234) so a screen-share looks like live software, or hash if two rows need to visibly share a customer. Reserve these for when realism matters; for tickets and bug reports, redact or drop is safer because there's no ambiguity about what's real.
Is it safe to screenshot before I anonymize?
No — that's the classic mistake. A screenshot or screen-share of the original file has already exposed the data; redacting afterward doesn't un-expose it. Always anonymize first, download the .anon.csv, and capture only from that scrubbed copy.
Does redact hide the column name too?
No — redact blanks the values but keeps the header. If the header itself is sensitive (like diagnosis or salary), use drop so the column and its name are removed from the file entirely.
Will the real file be uploaded when I scrub it?
No. PapaParse parses and transforms the file in your browser; only the scrubbed .anon.csv is produced. The sensitive original never reaches a server — which is exactly what you want when the goal is to avoid exposing it. A single no-content usage counter is stored server-side for signed-in stats.
How do I make sure I didn't miss a column?
Check the first-10-row preview after running, and scan every column — PII often hides in free-text fields (notes, subject, url) you didn't rule on. The tool only changes columns you add a rule for, so anything unruled passes through as-is. Redact or drop any column with identifying text before capturing.
Why didn't my redact rule do anything?
Most likely the rule's column name doesn't exactly match the header (email vs Email Address), so it never matched. Pick the column from the dropdown, which is populated from your file's actual headers. Also remember that adding any explicit rule disables auto-detect, so confirm you added rules for every column you intend to hide.
Can I just take a few rows for the screenshot?
Yes, and it's a good idea — a smaller slice screenshots more cleanly. Use csv-row-limiter to grab the first N rows first, then redact that slice. It also helps stay under the free-tier limits if you're not on Pro for the anonymizer.
Do mask stars guarantee the value is fully hidden?
Only if the kept characters reveal nothing meaningful. Mask keeps keepStart front and keepEnd back characters; if those counts are too generous for short values, you can leak most of one. For guaranteed full hiding in a screenshot, redact is safer — it removes the value entirely. Use mask only when a partial shape is genuinely needed.
Can I keep one column joinable in the demo while hiding the value?
Yes — hash that column. Because hashing is deterministic, two rows with the same hidden value show the same token, so a viewer can see they relate without seeing the value. Other columns you don't rule on pass through unchanged, so the rest of the demo data stays intact.
Can I automate scrubbing for a recurring report I share?
Yes — GET /api/v1/tools/csv-anonymizer returns the option schema; pair the @jadapps/runner and POST to 127.0.0.1:9789/v1/tools/csv-anonymizer/run. It runs locally so the real data never reaches JAD's servers. Handy for a weekly status export that you redact before pasting into a shared dashboard or deck.
Privacy first
Processing runs locally in your browser with PapaParse. No file is uploaded — only metadata counters are saved for signed-in dashboard stats.