Verify it yourself

Everything on this page is something you can check without trusting us.

1. The 30-second test: go offline

This is the strongest test, and it needs no technical skill.

1. Load elch.live once, so the application caches itself.
2. Turn off Wi-Fi, or switch the machine to airplane mode. Fully disconnect.
3. Reload the page. It still loads.
4. Choose your production folder and run a scan.

The scan completes, findings appear, repairs can be applied and exported — with no network at all. Software cannot upload your files over a connection that does not exist. If any part of the analysis depended on a server, this test would fail immediately.

Signing in and paying do need a connection, because those talk to our authentication and payment providers. The scan does not.

2. Watch the network yourself

1. Press F12 (or Ctrl+Shift+I / Cmd+Option+I) to open developer tools.
2. Select the Network tab and leave it open.
3. Scan a production folder.

You will see the requests that loaded the page itself, and — only if you are signed in — requests to Clerk (authentication) and Paddle (billing). You will not see a request carrying file content, because no such request is ever made. Sort by size: the large transfers are the application's own JavaScript arriving, not your evidence leaving.

3. The browser enforces it, not just our code

Every response from elch.live carries a Content Security Policy. Its connect-src directive is an allowlist of the only destinations this page is permitted to open a connection to:

That list contains our authentication provider and our own origin. There is no analytics endpoint, no file-storage bucket, and no third-party service capable of receiving a document. If a future bug — or a compromised dependency — ever tried to transmit your production somewhere, the browser would block the connection before it opened, and you would see the violation in the developer console.

Two further constraints work the same way:

• Parsing runs in a Web Worker on your machine. The DAT, OPT, LFP, and DII grammar, the hashing, the image inspection, and the repair are all executed by code running locally in your browser tab.
• Our service worker refuses to cache anything authenticated. Requests to /api/ and any request carrying an authorization header are network-only, never stored, so one session's account state can never be served to another.

What does leave your browser

To be complete and accurate, these are the only things that ever do:

• Your sign-in. Your email address and session are handled by Clerk so we can tell whether a subscription is active.
• Your subscription check and payment. Handled by Paddle as merchant of record. We ask only whether an account is entitled — never what it is working on.

None of these requests contain a filename, a file, a hash, a Bates number, a custodian, a matter name, or any other fact about your production. An entitlement check knows that an account is active. It does not know that a production exists.