gizmobench
BrowseDaily
← All guides

GizmoBench guides

Online Tools and Privacy: What Stays on Your Device

GizmoBench ·

An online tool is private when your input is processed inside your own browser and never sent to a remote server. You can check this yourself in a few minutes with your browser’s developer tools, and you should not rely on a tool’s marketing copy alone. Below, we explain what “private” can mean for a calculator, converter or file editor, how client-side and server-side processing differ, where offline web apps fit in, and which checks are worth doing before you paste in anything sensitive.

GizmoBench
Use Tools That Keep Files Local
GizmoBench tools run in your browser without an account or software installation, and file processing happens locally in the browser.
Explore GizmoBench tools

TL;DR

  • Client-side tools run code on your device, so inputs can stay there. Server-side tools send inputs to a remote machine, which increases data exposure.
  • Running in a browser does not make a tool automatically safe. Security and privacy are related but separate, and weak site security can still expose data.
  • You can verify local processing by opening the browser’s Network panel, using the tool, and looking for outgoing requests that carry your data.
  • Files carry hidden metadata such as location. Strip it before sharing, and prefer tools that do this locally.
  • Offline-capable web apps help with availability, but offline use alone does not prove that nothing is transmitted.

Table of Contents

What “privacy” means for an online tool

Privacy, in this context, is about control: how much personal information you hand over and who can access it. Microsoft’s guidance on internet privacy puts it as your ability to control how much personal information you provide and who can see it, and it lists what ordinary online activity can reveal: your IP address, email address, physical location, home or work address, and browsing activity.

For a simple tool, three kinds of exposure are worth separating:

  1. What you type or upload. A salary figure in a pay calculator, a name on an invoice, a photo in an image resizer, a JSON payload with customer records.
  2. What your browser reveals by default. Your IP address and request headers go to any server you contact, even if the tool never sees your file.
  3. What is hidden inside a file. Photos and documents can carry embedded descriptions of themselves, called metadata.

The second category is unavoidable on any website, including ours. The first and third are the ones a tool’s design can actually change.

What counts as personal information

Definitions are broader than most people assume. MDN’s privacy documentation lists contact details such as postal and email addresses, official identifiers like passport or social security numbers, physical attributes, health records and biometric data as personal information. The Canadian Centre for Cyber Security, citing NIST, adds that information linked to a person’s identity, such as home address or financial, education or employment information, also counts as personally identifiable information.

That matters for everyday tools. An invoice contains a business address and amounts. A resume contains employment history. A GPA calculation touches education records. None of these feels like a secret, but each fits the definitions above.

Invoice and resume papers on a desk

Client-side vs. server-side processing

This is the technical distinction behind most privacy claims, and it is also the question many readers search for separately.

Client-side means the code runs on your own device, in your browser. Cloudflare’s explainer describes client-side as code that runs on the end user’s device or in the browser, while server-side processing happens on a remote server and requests have to travel back and forth, which can add latency.

Server-side means your input is sent to someone else’s machine, processed there, and the result is returned. Google’s web.dev material on choosing a platform for AI features summarizes the trade-off: client-side processing keeps data on the machine, which can improve privacy, while server-side processing supports larger and more complex workloads but increases data exposure. The same guidance, in a related article, notes that client-side content is not sent to a server for processing and that any server-side fallback or other collection should be disclosed in a privacy policy.

Aspect Client-side tool Server-side tool
Where your input is processed In your browser, on your device On the provider’s server
Does the input leave your device? Not necessarily Yes, by design
Typical speed for small tasks No network round trip needed for the processing step Depends on connection and server load
Works for heavy workloads Limited by your device’s memory and CPU Can use far more computing power
What to verify That no request carries your data The privacy policy, retention and security practices

Neither model is wrong. A tool that converts a video or runs a large machine-learning model may reasonably need a server. The privacy question is whether the task actually requires one. A percentage calculation, a unit conversion or a password generator does not, and it makes little sense to send those inputs anywhere.

How we build the tools

Our position at GizmoBench is that tools should run locally wherever the task allows. By our own description, the tools work in the browser without an account or installation, and file processing happens locally in the browser rather than through uploads. That is our claim about our design, and the next section shows how you can test it rather than take our word for it.

Local does not automatically mean safe

It is tempting to treat “runs in the browser” as a guarantee. The evidence does not support that. MDN states that browser-based tools are not automatically privacy-respecting or secure: developers should collect as little data as possible and transport and store whatever they do collect securely. A tool can compute everything locally and still load third-party scripts, set tracking cookies or be served over a compromised connection.

MDN also treats privacy and security as distinct but linked. A well-written privacy policy does not help if the security underneath fails to keep out attackers, and strong security does not help if the policy permits broad collection. When you evaluate a tool, you are really asking two questions:

  • Privacy: what does it collect, and why?
  • Security: can that collected data be reached by anyone else?

For a client-side tool, the first question has a short answer if the tool truly sends nothing. Even then, check the connection (the padlock and HTTPS) and whether the page is loading unfamiliar scripts. Our SSL Checker lets you inspect the certificate, expiry and hostname of a site you are about to trust.

How to check where your data goes

You do not need to be a developer. Every major desktop browser ships developer tools with a network log. The steps below use Chrome, whose documentation describes the Network panel as the place that records a page’s network activity so you can see what is uploaded or downloaded. Other browsers have an equivalent panel.

A five-step check

  1. Open the tool page and load it fully, so the initial downloads are finished.
  2. Open DevTools (F12, or Ctrl+Shift+I on Windows and Linux; Cmd+Option+I on Mac) and select the Network tab. Chrome records requests automatically while DevTools is open, and the Network panel overview explains that the log can be cleared.
  3. Clear the log so that only new activity appears.
  4. Use the tool with harmless sample data. Type a made-up number, or open a throwaway test file, and run the operation.
  5. Read the new entries. For each request, check the Payload tab, which shows query-string parameters and form data, and the other tabs such as Headers and Response.

How to read the result

What you see What it likely means
No new requests after you run the tool The processing happened locally
Small requests to analytics or ad domains The page reports usage or loads ads; check whether the payload contains your input
A request to the tool’s own domain with your text or file in the payload The input was sent to a server
A large upload request after selecting a file The file is being uploaded for server-side processing

Two cautions apply. First, use sample data for the test, because the point is to find out before you commit real information. Second, a clean log tells you about the actions you tested, not every feature on the page. If a tool has a separate “save” or “share” button, test that too.

Files are the bigger risk: metadata

Typed numbers are low risk compared with files. Documents and photos carry embedded descriptive data. The Canadian Centre for Cyber Security notes that metadata can expose details such as geolocation from images or IP addresses from email headers and advises removing it before uploading files, to minimize exposure of personal information.

In practice, this affects three common situations:

  • Photos for a listing, forum or marketplace. A phone photo may include the place where it was taken. Our EXIF Remover strips photo metadata and keeps the pixels, and the walkthrough in our three-step guide to removing EXIF data locally shows the process.
  • PDFs you send to clients or post publicly. Author names, software and edit history can sit inside the file. The PDF Metadata Remover and Viewer lets you see and clear those fields.
  • Emails you forward for troubleshooting. Headers contain routing details. Our Email Header Analyzer reads hops and authentication declarations, so you can inspect a header without pasting it into a server-side service.

The design logic is simple. If a tool exists to remove sensitive information from a file, uploading the file first defeats the purpose. Local processing is the natural fit for this category.

Why a browser can handle your files without uploading them

Browsers include APIs that let a page read a file you have selected without sending it anywhere. MDN documents that the FileReader interface lets web applications read the contents of files stored on the user’s computer, and that it can only access files the user has explicitly chosen. Reading a file locally is therefore a normal browser capability, not a workaround. Whether a particular tool then transmits the contents is a separate matter, which is why the Network check above remains useful.

There is also a design principle at work. Canadian cyber security guidance on website design recommends that sites avoid file uploads where possible, because embedded content in uploaded files can expose sensitive information, and that they apply data minimization, meaning they ask only for the information needed for the purpose. A tool that never receives your file satisfies that principle by construction.

Offline web apps and what they do (and do not) prove

Another query that comes up is whether offline web apps are private. The short answer: offline capability is about availability, and it tells you less about privacy than people expect.

Offline web apps typically rely on service workers. MDN describes them as proxy servers between web applications and the network, which enable offline experiences and cache resources, and says they are available only in secure contexts such as HTTPS. Three practical consequences follow:

  • A cached app can work without a connection, which is useful on a plane or with unreliable signal. Whatever the tool processes in that session cannot be sent anywhere while you are offline.
  • The same app may sync when you reconnect. An app that works offline can still queue your data and send it later. Offline behavior does not prove that the data is never transmitted.
  • Caching is stored on your device. Cached resources and any locally saved data sit in your browser’s storage, so on a shared computer you should clear site data afterward.

A useful test: switch your browser to offline mode in DevTools after the page loads, then run the tool. If it still works, the processing is local at least for that function. Then reconnect and look at the Network log for any delayed requests.

Before you enter personal information or upload a file

The Canadian Centre for Cyber Security’s guidance on using applications gives a sensible checklist: review permissions and the privacy policy, ask whether the data is necessary, remove metadata from media where appropriate, and research the provider’s security practices. It also recommends limiting what you share and keeping software updated. Adapted to ordinary web tools, that becomes:

  1. Ask whether the tool needs this data at all. A pay calculator needs numbers, not your employer’s name. Use placeholders for names and account numbers when the calculation does not depend on them.
  2. Prefer tools without sign-up. An account creates a stored record linked to you. Where a tool does ask for an email address, a throwaway address is a reasonable choice, as the same guidance suggests.
  3. Read the privacy policy for retention. The questions are what is collected, how long it is kept, and who receives it.
  4. Check the connection. Look for HTTPS before entering anything.
  5. Remove metadata before sharing files, regardless of which tool you used to create them.
  6. Test with sample data first, using the Network check above.

One point from Microsoft’s guidance is worth keeping in mind for the whole list: once data is published online, it is effectively there for good and may be exposed through hackers or security lapses. Prevention is easier than removal.

Small businesses and internal tools

Freelancers and small teams often paste client data into whatever tool is nearest: an invoice template, a JSON snippet, a spreadsheet converter. The exposure here is not only yours, it belongs to your customers. Broader guidance on application security for small firms, such as this overview of security for small business apps, covers the organizational side. For the individual tool choice, the same principle holds: send as little as possible, and prefer local processing for anything with customer details.

Which kinds of tools suit local processing

Not every task has the same sensitivity. A rough grouping, based on what the input usually contains:

Task What the input may contain Why local processing helps
Invoices and resumes Names, addresses, amounts, employment history Business and personal identifiers stay on your device
Photo and image edits Faces, locations in metadata Photos are not copied to a third party
Data formatting (JSON, Base64) Tokens, customer records, API keys Credentials are not pasted into a remote service
Passwords The generated secret itself A password that was generated remotely has existed elsewhere
Unit, percentage, age and similar calculations Usually low sensitivity Mostly a convenience; a local tool is simply faster

Developers get a particular benefit. Pasting a production config into a server-side formatter can leak keys without anyone noticing. Formatting code with our JavaScript Beautifier, or rendering a pasted snippet in the HTML Viewer, keeps that content in your own browser tab, based on how we built them. Redirect and robots.txt checks are different: tools like the Redirect Checker examine public URLs, so there is no private file involved.

Where GizmoBench fits

GizmoBench is a collection of calculators, converters, generators, editors, viewers and file utilities that run in the browser without an account. The catalog covers everyday numbers, work documents, developer utilities, 3D files and more. If you want to put the checks from this article to use, start with the everyday tools, try the work tools such as the Invoice Generator, or browse everything from the GizmoBench homepage. Core tool functions need no account, and we recommend running the Network check on any of them. We expect it to show what we describe, and the check is the point of this article: you should not have to take our word for it.

FAQ

Is a free online tool safe to use with personal data?

It depends on where the processing happens and how the site is secured, not on the price. A tool that processes locally and sends nothing carries less exposure than one that uploads your input. Check the Network panel with sample data first, and avoid entering identifiers the task does not need.

What is the difference between client-side and server-side processing?

Client-side processing runs in your browser on your own device, so inputs do not have to leave it. Server-side processing sends inputs to a remote machine and returns the result, which supports heavier workloads but increases data exposure. Many sites mix the two, so the useful question is which part handles your data.

Are offline web apps more private?

Not automatically. Offline apps use service workers to cache resources so the app can run without a connection, but they may still send data when you reconnect. Treat offline capability as a convenience, and verify privacy through the Network panel and the privacy policy.

How can I tell if a tool uploads my file?

Open the browser’s developer tools, go to the Network tab, clear the log, and then select a test file. A large outgoing request, or a request whose Payload tab contains your file or text, means it was uploaded. No new requests suggests local processing for that action.

Should I remove metadata from photos and PDFs before sharing them?

Often yes, especially for photos that may contain location data and documents that carry author details. Canadian cyber security guidance advises removing metadata before uploading files to reduce exposure of personal information. A local metadata remover lets you do that without sending the original file anywhere.

Sources