# How Lutrakit processes files in your browser — and how to verify it

Lutrakit’s file tools are free, require no account, and are designed so the files you choose are read by the browser, processed by JavaScript running on your device, and downloaded back as a new local file. They should not upload your file contents or filenames to a Lutrakit application server. The practical way to trust that promise is not to take the sentence on faith: run the tool with the browser’s Network panel open and check what requests happen while the file is selected and processed.

This guide explains the boundary, gives a reproducible test, and records what that test can and cannot prove. To check the current production build yourself, rerun the workflow below and record the browser, operating system, sample files, and observed network log.

## What “browser-only” means here

When a web page lets you choose a local file, the browser exposes that chosen file to page code through web platform APIs. The W3C File API defines the browser objects used to represent selected files and access their data in web applications. That access starts from a user selection, such as a file input or drag-and-drop interaction, not from open-ended access to your computer’s file system. See the W3C [File API specification](https://www.w3.org/TR/FileAPI/) for the standard boundary.

Lutrakit’s heavier tools, such as PDF and audio processing, may run work in a Web Worker. A worker is still browser-side code; it is a separate execution context linked to the page, useful for keeping long work off the main interface thread. The WHATWG HTML standard describes dedicated and shared workers as worker contexts that communicate with their creator through message passing, not as remote servers. See [HTML Standard: workers](https://html.spec.whatwg.org/multipage/workers.html).

There are three separate things that can be easy to confuse:

- Loading the site: the browser requests HTML, JavaScript, CSS, icons, and other assets from the site.
- Loading a processing engine: a tool may download code it needs the first time you use it. That request should not contain your file.
- Processing your selected file: the file bytes should stay in the page, worker, memory, and downloaded output path inside the browser.

The privacy-sensitive claim is the third one. A page load always uses network requests; the question is whether choosing and processing a file creates a request that carries your file bytes, filename, extracted text, waveform, signature image, or other local content.

## A verification workflow you can repeat

Use a harmless sample, not a confidential document. If you need to test a private file, do not export or share a HAR log unless you understand exactly what it contains; Chrome’s own Network reference notes that HAR export can include sensitive data when not sanitized. Chrome DevTools also documents that the Network panel records requests while DevTools is open and can preserve logs across reloads: [Chrome DevTools Network reference](https://developer.chrome.com/docs/devtools/network/reference).

1. Open a fresh browser profile, private window, or test profile with extensions disabled.
2. Open DevTools, go to the Network panel, enable “Preserve log,” and enable “Disable cache.”
3. Load the Lutrakit tool you want to test. For a PDF example, open the [Merge PDF tool](/pdf-merge/).
4. Wait until the page finishes loading. The initial HTML and static assets are expected.
5. Clear the Network table so the next entries are only from the file-selection and processing phase.
6. Choose a sample file whose filename and visible content contain a unique canary string, for example `lutrakit-local-canary-2026-08-17`.
7. Run the tool.
8. Look for any request made after file selection. Check method, URL, request payload, query string, headers, and response. In Chrome, use the request details panes and the global search tab.
9. Search the Network data for the canary filename and content string.
10. Repeat with the browser offline after the tool has already loaded, where that tool supports repeat use without first-run downloads.

What you want to see is simple: no request whose body, URL, header, or query string contains the file’s contents, filename, extracted text, signature image, or other user-selected file data. It is normal to see no new requests at all during processing, or to see only tool-engine asset requests on a cold first run. Those asset requests should be same-origin static code requests and should not include the file.

## Worked example: two tiny PDFs

Use two one-page PDFs created for testing:

- `alpha-lutrakit-local-canary-2026-08-17.pdf`, page text: “Alpha local canary 2026-08-17.”
- `beta-lutrakit-local-canary-2026-08-17.pdf`, page text: “Beta local canary 2026-08-17.”

Open [Merge PDF](/pdf-merge/), clear the Network panel after the tool has loaded, select both PDFs, keep the default output name or set `local-canary-merged`, and run the merge. The expected local result is a two-page PDF in the selected order. The expected network result is that the canary filename and page text do not appear in any post-selection request.

This is also a useful regression test for the interface: the merge tool requires at least two PDF files, accepts `application/pdf`, enforces a current per-file limit of 100 MB and a current combined input limit of 300 MB, and lets you set the downloaded filename. Those limits come from the current Lutrakit source and can change, so check the live interface before relying on them.

## How to read the results

The useful question is not “is the Network table empty?” but “is there a network path for my file data?”

| Result | Interpretation |
| --- | --- |
| Only page assets before you selected a file | Normal site loading. |
| A first-run JavaScript, worker, WASM, or library asset loads before processing | Acceptable if it is static code and carries no file data. |
| No requests after the file is selected and processed | Strong evidence for browser-only processing for that run. |
| A request after file selection with the filename, extracted content, or binary body | Treat as a failure and do not use the tool with private files. |
| A request from an extension, password manager, antivirus, or corporate proxy | Test again in a clean profile; that may not be Lutrakit traffic. |

Network panels can miss requests that happened before DevTools opened, which is why the workflow opens DevTools first. They also do not prove that your operating system, browser account sync, cloud backup, or third-party browser extension did nothing with the file. The test verifies the web page’s browser-network behavior in the environment you actually used.

## Browser storage and saved signatures

Most Lutrakit file tools do not need to keep your files after the output is generated. A few site preferences or utility states can be stored in the browser. For example, the PDF signature tool can save a reusable visual signature only when you choose to save it. Browser `localStorage` is origin-bound storage that persists across sessions, as described by MDN’s [Window.localStorage reference](https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage). That means a saved signature can remain on the same browser profile until you remove it with the tool controls or clear site data.

For shared computers, school computers, or work devices, do not save a reusable signature. Draw or import it for the current file only, download the result, then clear the signature and site data if needed.

## Limits: when browser-only is not enough

Browser-only processing reduces one important risk: your selected file does not need to be handed to a remote conversion service. It does not make a tool suitable for every sensitive document.

Do not use a browser utility as your only control when:

- the document is legally privileged, regulated, classified, or subject to a strict workplace policy;
- you must prove a certified chain of custody;
- you need a digital certificate or qualified electronic signature, not a visual mark;
- the output must preserve advanced PDF features such as all metadata, forms, bookmarks, attachments, tags, layers, scripts, or signatures;
- the PDF is damaged, encrypted, unusually large, or safety-critical.

In those cases, use approved local software, your organization’s document system, or a specialist workflow. For ordinary school, personal, and low-risk office documents, the browser-only model is often enough when the output is verified before sharing.