Browser-local privacy guide
Know what “processed in your browser” means before choosing a private image tool
A browser tool can edit an image without uploading the file, but that does not make every network request disappear. The useful question is narrower: where do the selected pixels, entered words and generated files go? A trustworthy tool should state that boundary, identify exceptions and give people a practical way to inspect it.
Quick reference
| Activity | Where it happens | What can reach a server |
|---|---|---|
| Select text, an image or a logo | The browser exposes only the file the visitor chooses. | Nothing unless the application explicitly uploads it. |
| Edit, render and export | JavaScript and Canvas process the working pixels on the device. | Nothing from the creative content in a local-only workflow. |
| Load the website | The browser requests HTML, CSS, JavaScript, fonts and images. | Ordinary request data such as IP address, URL and browser information. |
| Use ImageFromText background removal | The selected image is processed on the device after the runtime and model arrive. | jsDelivr and Hugging Face receive asset requests, not the selected image. |
| Use analytics, feedback or contact | Only the disclosed measurement or submitted form fields are sent. | Aggregate usage metadata, optional feedback, or contact details—not creative content. |
Local processing is a data boundary, not a promise of zero network traffic
The browser must normally request the application before it can run it. Hosting logs can therefore receive the same basic request information involved in visiting other websites. Analytics, externally hosted libraries or optional models may create additional requests. None of that proves that a selected image was uploaded, but each request should be documented accurately.
For ImageFromText, text-image creation and the ordinary image utilities use browser APIs. Selected images, typed words, logos, QR content and generated exports remain on the device. The privacy notice separately describes analytics, hosting logs, optional feedback, contact messages and the external runtime/model requests used by Background Remover.
Trace the file instead of relying on a privacy badge
- Read the exact claimLook for a statement about selected files and creative content, not only a broad word such as “secure” or “private.”
- Open the browser Network panelClear the log, select a non-sensitive test image, make an edit and export. Inspect requests created by those actions and their payloads.
- Distinguish asset downloads from uploadsA model, font or script can be downloaded without sending the selected file. Check the request direction, destination and body instead of judging by the domain name alone.
- Repeat with the network unavailableAfter the application and any required assets are cached, try the core workflow offline. Offline success is useful evidence, although it does not replace reviewing the online requests.
- Use harmless test contentDo not upload a confidential file merely to test a privacy claim. A synthetic screenshot can expose the same data path without creating new risk.
Understand what can still leave the device
- Page and asset requestsThe host and any named asset provider can receive IP address, requested URL, time and browser information while delivering the application.
- Aggregate analyticsImageFromText queues page and predefined tool events without text, filenames or project names. The external analytics library starts after interaction or a short delay.
- Optional feedbackA yes/not-quite response, optional suggestion, page or tool name, broad device category and submission time are sent only when feedback is submitted.
- Contact messagesThe name, email address, topic and message entered into the contact form must be sent so the maintainer can respond.
- Third-party model deliveryBackground Remover downloads a reusable browser runtime and model. The chosen image stays in the local processing path.
Local tools still need honest failure and storage guidance
Local processing shifts work to the visitor’s device. Very large images can exceed available memory, browsers can close a tab, and clearing site data can remove unsaved projects. A privacy benefit should not be presented as perfect durability or universal device support.
Download important exports and save editable project files where the tool offers them. Keep the original image separately. When a browser feature such as clipboard access, local AI, file-system integration or offline caching varies by device, the product should say so instead of promising identical behavior everywhere.
A developer checklist for truthful browser-local tools
- Keep the file path explicitRead user-selected
Fileobjects locally and do not put them intoFormData, Fetch or XMLHttpRequest unless an upload is a clearly requested feature. - Render and export on the deviceUse Canvas, SVG or another suitable browser API, and create the downloadable Blob locally. Revoke temporary object URLs when they are no longer needed.
- Inspect every event payloadAllowlist analytics fields. Exclude entered text, QR payloads, filenames, project names, image data and arbitrary URLs.
- Cache deliberatelyA service worker can make core assets available offline, but cache versions and asset lists must stay aligned with releases.
- Document exceptions beside the claimName third-party assets, optional server submissions, browser storage, retention and realistic device limitations in plain language.
- Test the boundaryUse the browser Network panel and automated request interception to confirm that creative content does not cross it. Recheck when dependencies or analytics change.
Example: prepare a sensitive screenshot without sharing its pixels
Create a synthetic copy for the first test. Open the Network panel, select it in the annotator or blur tool, cover the sensitive region, export and inspect the requests. Then verify the exported pixels at full size before using a real screenshot. Solid redaction is safer than a decorative overlay when the underlying text must not remain visible.
The result should be a downloaded file created by the browser. If the workflow unexpectedly sends a request containing the image, stop and investigate before using the tool with private material.
Primary references
Platform specifications change. These first-party references were checked when this guide was updated.