How browser-based tools handle your data

A browser application is downloaded as HTML, CSS, and JavaScript, then executed on your device. Once loaded, JavaScript can count words, resize an image, calculate a loan payment, or encrypt text without sending the input back to the website. The File API lets a page read a file you deliberately select, while Web Crypto provides browser-native cryptographic operations.

That architecture is materially different from a server tool that uploads a file or form value for processing. It can reduce data exposure and latency, and it allows many tools to keep working after the initial page assets have loaded. It does not mean the website makes zero network requests or that every client-side page is automatically trustworthy.

Suppose you paste text into a word counter. The counter can analyze that text entirely in memory while the page separately records a generic event such as “word counter opened.” Those are two distinct data flows. A careful privacy claim should say whether the actual text or file is transmitted, not imply that the page has no analytics, logs, cookies, or hosting requests at all.

On Handiwork, local-processing claims refer to the values placed inside the tool: text, numbers, selected files, generated passwords, and similar working data. The privacy policy separately describes technical usage information and third-party services. That distinction is more precise than saying a website is simply “private.”

Data held only in component memory normally disappears on refresh or when the tab closes. Local storage is different: it is a browser database for a specific site and persists until code or the user clears it. Handiwork uses local storage for preferences and for features that explicitly promise persistence, such as the notepad and saved calculator inputs.

A downloaded file leaves the page and becomes your responsibility. It may be backed up, synced to cloud storage, indexed by the operating system, or retained in a downloads folder. Local generation prevents a server upload; it does not control what happens to the resulting file afterward.

Open the browser developer tools, select the Network panel, clear the existing log, and then use the tool with harmless sample data. Look for a request triggered by typing, selecting a file, or pressing the action button. A purely local operation should not need to upload the working value. Testing with synthetic data avoids exposing the very information you are trying to protect.

You can also disconnect the network after the page has loaded and repeat the action. If the tool still works, that is useful evidence of local execution, though it does not prove that the code never transmits data when connectivity returns. For serious assurance, inspect or self-host the source and pin the exact version you reviewed.

A remotely served page can change between visits, and browser extensions or a compromised device can read page content. Do not paste production private keys, recovery seeds, active passwords, regulated records, or incident evidence into an arbitrary website merely because it says processing is local.

Use approved, audited, and preferably offline software when a disclosure could cause material harm. Browser tools are well suited to routine calculations, public text, disposable test data, and low-risk transformations. The correct boundary depends on the sensitivity of the input and the assurance you need.