Why Your Data Never Leaves the Browser — and Why That Matters
Most tools that ask you to paste data into a text box send that data to a server. The processing happens on a computer you don't control, owned by a company you may not have vetted, in a jurisdiction you might not know. The result comes back to you. The original data may or may not be retained.
dedup.ing works differently. When you paste a list or upload a file, the processing happens entirely inside your own browser — on your machine, in your memory. No data is transmitted. The server that delivers the page plays no further role once the page has loaded.
This is called client-side processing, and it has real consequences for what you can and cannot safely do with a tool.
What "Client-Side" Actually Means
Client-side processing means the computation runs in your browser, using your device's CPU and memory, without sending data to a remote server. The web page delivers the code; your browser executes it locally.
The alternative — server-side processing — means your data travels over the network to a remote computer, gets processed there, and the result is sent back. Every paste into a server-side tool is a network request containing your data.
Most web tools use server-side processing because it's easier to build, easier to scale, and gives the provider access to usage data. Client-side tools require the developer to ship the processing logic as JavaScript that runs in the browser — more technically constrained, but the only architecture that gives users a genuine privacy guarantee.
For dedup.ing, the entire deduplication engine lives in packages/dedupe-core — a TypeScript package that ships with the page and executes in a Web Worker, a background thread in your browser. Your list data is passed to that worker, processed, and returned. It never becomes an HTTP request.
Why It Matters for Real Data
The privacy distinction is theoretical until you consider what actually goes into a deduplication task.
Contact lists. An email list being prepared for a send contains names, email addresses, and often phone numbers or job titles. Pasting it into a server-side tool means that data is now on someone else's server. Whether it's logged, retained, analyzed, or sold depends entirely on that company's privacy policy — and how well they actually follow it.
Customer exports from a CRM. A deduplicated CRM export often contains full customer records: purchase history, company name, account status. Under GDPR and CCPA, transmitting this data to a third-party processor requires a Data Processing Agreement (DPA). Most free online tools don't offer one.
Internal company data. Mailing lists, vendor lists, employee directories, product SKUs — the kind of data that appears in internal spreadsheets wasn't intended to leave your organization's systems. Pasting it into an online tool crosses a boundary many IT and compliance teams prohibit explicitly.
Medical or financial identifiers. A list of patient IDs, policy numbers, or account codes may be subject to HIPAA, PCI-DSS, or similar regulations. Server-side processing of that data through an unvetted tool creates compliance exposure regardless of intent.
Client-side processing sidesteps all of these concerns. The data stays on the device where it originated. No DPA is required because no third party receives the data. No retention policy needs to be reviewed because no retention occurs.
How to Verify It Yourself
A privacy claim in a product description costs nothing to make. Verification takes about thirty seconds.
In Chrome:
- Open dedup.ing.
- Press
F12to open DevTools. - Click the Network tab.
- Paste a list into the tool and click Dedupe.
- Watch the Network panel.
You will see requests for static assets — the page itself, CSS, JavaScript files — loaded when the page first opens. You will see no outbound request containing your list data when you click Dedupe. The processing produces no network activity.
In Firefox: the same steps apply. Open DevTools with F12, use the Network tab, and filter by XHR or Fetch to focus on data requests specifically.
If you want to be thorough, paste a distinctive string into the input — something unique like verify-privacy-test-12345@example.com — and filter the Network tab for that string. It will not appear in any request.
This verification method works for any online tool. Before pasting sensitive data into a tool that claims to be "private" or "secure," take thirty seconds to check the Network tab. The presence of an outbound request after you interact with the tool is the tell.
Client-Side vs. Server-Side: The Practical Tradeoffs
Client-side processing is the right architecture for privacy, but it comes with real constraints worth understanding.
| Client-side | Server-side | |
|---|---|---|
| Data leaves your device | Never | Always |
| Who can see your data | Only you | The tool provider (and their infrastructure) |
| Processing speed | Limited by your device | Scales with server capacity |
| Row limit | Bounded by browser memory | Essentially unlimited |
| Works offline | Yes, once loaded | No |
| DPA / compliance required | No | Often yes, for regulated data |
| Verification | Network tab shows no requests | Network tab shows data requests |
dedup.ing handles up to 500,000 rows client-side. Above that, the memory constraints of a browser tab become a practical limit. For lists in the millions-of-rows range, a local script (Python's pandas.drop_duplicates(), or a shell sort -u) is more appropriate than any browser tool — client-side or otherwise.
The One Exception
One feature on dedup.ing does involve server storage: the optional shareable result URL (Pro tier). When you create a shareable link, your deduplicated result is uploaded to Supabase storage and assigned a URL you can send to someone else. The result expires automatically after 30 days.
This is opt-in, explicit, and distinct from the core tool. The deduplication itself still runs client-side. Only the final result — not your original input — is stored, and only if you choose to create a shareable link.
The core tool — paste, deduplicate, copy or download — involves no server storage at any step.
What This Means in Practice
Three takeaways for anyone who works with lists regularly:
You can use dedup.ing on data you couldn't send to a third-party tool. Customer exports, internal directories, regulated identifiers — if the data can't leave your machine, it can still be deduplicated here.
"Free" tools have costs that aren't monetary. Many free online tools sustain themselves by analyzing usage patterns, which requires seeing your data. Client-side tools don't have that model — they can't analyze data they never receive.
Verify before you paste. The Network tab check takes thirty seconds and works on any tool. Make it a habit before pasting anything sensitive into a browser-based tool you haven't evaluated before.
Frequently Asked Questions
Does dedup.ing store my list when I paste it in?
No. The list is passed to a Web Worker in your browser, processed locally, and returned. No network request is made with your data. You can verify this by watching the Network tab in your browser's DevTools while running a deduplicate operation.
What about the file I upload — is that sent to a server?
No. Files dragged into the tool or selected via the file picker are read by the browser's File API and passed to the client-side processing worker. They are not uploaded to any server.
Does this mean dedup.ing has no servers?
dedup.ing has a server — it delivers the web page, hosts the API (for the developer tier), and stores shareable result URLs (for Pro users who opt in). The distinction is that the deduplication computation runs in your browser, not on those servers. The server's role ends once the page and its JavaScript have been delivered to your device.
Is client-side processing slower than server-side?
For most list sizes, no. The deduplication engine uses a Web Worker so it doesn't block the browser's UI thread, and modern JavaScript set operations are fast. On 50,000 rows, results appear in under two seconds on a typical laptop. On 500,000 rows, expect under ten seconds. For lists larger than that, a local script will outperform any browser tool.
If I use dedup.ing at work, do I need to get it approved by IT?
That depends on your organization's policies. Because no data is transmitted to a third party during normal use, many IT and compliance policies that would otherwise apply to SaaS tools don't apply here. The relevant question for your IT team is: "does this tool transmit user input to a third-party server?" The answer, for the core deduplication tool, is no — and you can demonstrate that with a Network tab recording.
What's a Web Worker and why does it matter?
A Web Worker is a background thread in the browser. It can run JavaScript without blocking the main page — so while your list is being processed, the rest of the interface stays responsive. It also enforces a separation between your page's UI and the processing logic. The dedup.ing worker receives your list data, processes it, and sends back the result. It has no access to cookies, localStorage, or any other browser state.
Get new tutorials in your inbox.
No spam, just useful updates when we ship something new or write something worth reading.