Use Everyday Tools

HOW-TO GUIDE · BROWSER-FIRST WORKFLOWS

What browser-local file processing protects—and what it does not

Understand local processing, helper-library requests, analytics, downloads and shared-device risks.

Local processing is a data-flow claim

When a tool processes a selected file locally, the file bytes are read and transformed inside the browser rather than submitted to this site’s processing server. That is different from a server converter that uploads the document for transformation. The page still needs to load, and helper code may make ordinary network requests. Local does not mean no network activity of any kind.

Check the claim yourself in two minutes

You do not have to take a privacy statement on trust, because a browser lets you watch what a page sends. Open the tool page, then open your browser’s developer tools (usually F12, or Ctrl+Shift+I, or Cmd+Option+I on a Mac) and choose the Network tab. Clear the list, then choose a test file and run the tool.

What you should see is requests for the page’s own scripts, styles, fonts and libraries, all from this site’s address. What you should not see is a large POST request carrying your file’s bytes to a server. The size column is the quickest signal: if a 20 MB PDF were being uploaded, a request of roughly that size would appear. Try the same test on any other online tool you use, and compare.

This check proves the data flow for the version of the page you have open, which is the reason it is better than a promise. If a page ever behaved differently from its description, the contact page is the right place to report it.

Understand helper libraries and language data

PDF rendering, image decoding and OCR depend on open-source libraries. This site serves those libraries from its own server, so using a tool does not send your file to another company, and the browser caches them after the first visit. OCR also needs language data, which is likewise downloaded from this site the first time you use it. These downloads are requests for software, not uploads of your document. Like any web request, they let the server see network metadata such as your IP address.

There is one deliberate exception: the currency converter asks a public exchange-rate service for the latest rates. That request contains no files and no amounts you typed, only the request for current rates. A fully disconnected workflow would need every dependency stored in advance, and this site does not promise complete offline support.

Metadata and hidden content travel with the file

A document can carry information that never appears on the page. Photos often contain the camera model, the date and sometimes GPS coordinates. PDFs usually store an author, a creating application, dates and sometimes comments or earlier revisions. Office documents can keep tracked changes and hidden text.

Local processing does not remove any of this unless a tool is designed to. Before you share a file outside your organization, inspect what it carries. The Image Metadata tool shows what a photo records, and the PDF Metadata tool shows and edits a PDF’s document properties. Treat the results as a check on the properties, not as proof that nothing sensitive remains inside the pages themselves.

Separate document privacy from analytics and the contact form

Optional analytics measures page visits and high-level tool actions, and only after you give permission. It is not designed to receive filenames, pasted text, passwords or document contents. You can decline it and still use every tool. Theme preferences and your analytics choice are kept in your browser’s storage.

The contact form is a different data flow and is described in the privacy policy. When you send a message, the details you type are submitted to this site’s own mail server and emailed to the publisher. No file from any tool is attached, so do not paste confidential document contents into a support message; describe the symptom instead.

Protect the device and the output

A browser extension, compromised device or shared download folder can expose information even when the tool itself never uploads the input. Use a trusted device, follow your organization’s policy and pay attention to where downloads are saved. Comparison reports and extracted text may be as sensitive as the original document. Delete or store them under the appropriate retention rules after use.

What local processing does not protect against

Keeping a file on your device removes one risk, the upload, and leaves the others. Think through the rest of the chain before you decide a workflow is safe enough.

  • A browser extension can read page content and your files; review which extensions have access on a shared or work machine.
  • A shared or synced downloads folder can copy a finished file to a cloud service you did not intend to use.
  • Clipboard history, screenshots and screen sharing can capture text you pasted or a page you displayed.
  • The output may be as sensitive as the input. A text extraction or a comparison report contains the document’s words.
  • A lost laptop or an unlocked screen exposes whatever is open. Close the tab and clear downloads you no longer need.

Choose the right workflow for the document

For especially sensitive or regulated records, use organization-approved software and controls rather than treating a privacy badge as a blanket security guarantee. Local processing is useful risk reduction, not a certification or legal assurance. Keep originals, verify outputs and do not confuse structural PDF validation with malware analysis, authenticity checks or digital-signature validation. Read the privacy policy for the specific data flows before starting.

Questions to ask any online file tool

Use the same short list whenever you meet a new tool, whether it is this one or another provider’s. The answers should be easy to find in the tool’s documentation or privacy policy, and a vague answer is information in itself.

  • Is my file uploaded, and if it is, to which company and which country?
  • How long is the file kept, and who can access it while it is stored?
  • Is the file used for anything other than producing my result, such as analytics or training?
  • What does the tool log: filenames, sizes, text I typed, my IP address?
  • What happens if the page cannot finish processing: does anything partial remain somewhere?
  • Does my organization’s policy allow this class of document to be processed with this kind of service?

A simple handling rule for small teams

Teams get into trouble when everyone makes a separate judgment about every file. A short rule removes most of the guesswork. Sort documents into three bands. Public material, such as a brochure, can go through any reputable tool. Internal material, such as a draft report, should use tools whose data flow you have checked, which is where a local tool helps. Regulated or highly confidential material, such as medical, financial or legal records, should use only software your organization has approved, whatever any website promises.

Write down which tools are approved for which band, and who to ask when a case is unclear. Keep it to one page. A rule people can remember is followed; a policy document nobody reads is not.

Before you finish

  • Keep an untouched original and use a separate filename for the result.
  • Test a representative sample before processing the full document.
  • Review the actual downloaded file in the receiving app, not just a preview.

← More practical guides · Report an error or suggest an improvement

Try a known sample first

Use synthetic files with expected page counts, text and form values. Compare the actual downloaded result, not just the preview.

Worked examples and sample files · Testing approach and limitations