Security & Privacy: What You Can Verify Yourself

1. How file processing actually works, step by step

When you drag a file onto the dropzone or click "Upload My EDI File," here is precisely what happens, in order:

1. Your browser's built-in File object receives a reference to the file from your operating system's file picker or drag event. No network request has occurred yet.
2. JavaScript calls the browser's native FileReader.readAsText() API, which reads the file's bytes into a JavaScript string variable, entirely inside the browser process running on your own device.
3. The parser (js/parser.js) inspects that in-memory string for the ISA header (X12) or UNA/UNB header (EDIFACT), determines the delimiters, and splits the text into segments, elements, and values — all with plain JavaScript string operations, no network calls involved.
4. The resulting structured rows are stored in a JavaScript variable (state.parsed in js/main.js) and rendered into the on-page HTML table you see.
5. When you click Export CSV/Excel/JSON, the same in-memory data is formatted and handed to the browser's native "download a Blob" mechanism (URL.createObjectURL), which saves the file straight from browser memory to your device's downloads folder — again, no server round-trip.

At no point in this sequence does the file content pass through a fetch(), XMLHttpRequest, form submission, or any other network-sending API. That's not a policy promise — it's a statement about which lines of code exist in the shipped JavaScript, and you're welcome to verify it in the next section.

2. How to verify this yourself in under two minutes

You don't need to trust this page. Here are two independent ways to confirm the "no upload" claim on your own machine:

Method A — Watch the Network tab

1. Open this site, then open your browser's Developer Tools (F12 or right-click → Inspect) and switch to the Network tab.
2. Clear the network log, then drag in an EDI file (or click one of the free sample files).
3. Watch the Network tab as the table populates. You will see no new outgoing request containing your file's bytes — the only requests that were made had already fired before you touched the file (loading the page's own scripts, fonts, and the analytics/checkout scripts).

Method B — Go offline

1. Load the page fully first (so the scripts have downloaded).
2. Turn off your Wi-Fi or unplug your network connection.
3. Upload a file and click Export CSV. It will still work — because nothing about parsing or exporting requires a live network connection. A tool that actually uploaded your file to a server for processing could not do this.

3. What is not stored, and for how long

• No server-side storage of file content, ever — there is no backend endpoint that accepts file uploads on this site at all.
• No browser-persistent storage of file content — parsed data lives only in an in-memory JavaScript variable for the life of the tab. It is not written to localStorage, sessionStorage, IndexedDB, or cookies. Closing or refreshing the tab discards it completely.
• What is stored locally: an unlock flag (localStorage['edi_parser_unlocked']) and, if you unlocked with a purchase, your Gumroad licence key and order id. These record only your purchase status — they contain no file data whatsoever.
• The one outbound request that isn't analytics: unlocking with a purchase sends your licence key to Gumroad's licence API to verify it (and re-verifies a cached key at most once a day). That request carries your key and the product identifier — not a device label, and never file content. If you never enter a licence key, this request never fires.
• Analytics events (Google Analytics 4, via js/analytics.js) record only metadata: file extension of rejected uploads, the detected EDI standard (X12 or EDIFACT), segment count, and record-group count. Never the file name, and never any parsed field value or business data from inside the file.

4. Third-party scripts this page loads, and why

For full transparency, here is every third-party script this site loads and what each one does — none of them receive your EDI file content:

5. Who this local-processing model is especially useful for

Because no file content ever reaches a server, this tool is a reasonable fit for a quick, one-off look at files that a team may not want to paste into a generic online converter, including:

• Healthcare billing teams inspecting an 837 claim or 835 remittance file without routing protected health information through a third-party server.
• Finance and procurement teams spot-checking an 850 purchase order or EDIFACT INVOIC invoice that references real supplier pricing or account details.
• Consultants and support staff troubleshooting a client's EDI file on a shared or unmanaged machine, where uploading the file anywhere would violate a client confidentiality agreement.

None of this is a guarantee that local-only processing is sufficient for your specific regulatory obligations (HIPAA, GDPR, or otherwise) — it only guarantees that this particular step of your workflow doesn't add a new third party into your data's path. See our Privacy Policy for the full legal treatment of data handling.

Frequently Asked Questions