“Runs locally” is a phrase used loosely in file-tool marketing. Sometimes it means the processing happens on your computer. Sometimes it means a server is in the same country. Sometimes it means very little at all. It is worth knowing the difference, especially when the file is a contract, a medical record, or a photo you would not post publicly.

What “local” means in a browser

A web page is a program. Once it has loaded, that program runs on your computer, not on the server that delivered it. Most of the time we do not think of a website this way because the interesting work traditionally happened on a server: form submissions, searches, image conversions.

Modern browsers can do much more than display forms. They can read a file you choose, decode an image, parse a PDF, run JavaScript or WebAssembly, and generate a new file for you to download. A local file tool is simply a page that does these things without sending the file anywhere. The server’s job ends when the page is delivered.

That is different from a conventional online converter, where your file is uploaded to a server, processed remotely, and downloaded again. Uploading creates a copy outside your device. Even if the service deletes it promptly, the copy existed, and the promise of deletion is only as good as the service’s practices.

How a browser handles a file

When you choose a file in a file input, the browser gives the page a File object. It contains metadata such as the name and size and provides a way to read the contents. The page can read those bytes into memory, draw an image to a canvas, open a PDF with a parsing library, or pass the data to a Web Worker so a long operation does not freeze the interface.

The file is still sitting on your disk. The tool is working from a temporary in-memory copy. When the page closes, that copy is discarded. A downloaded result is a new file created by the browser; the original is untouched unless you deliberately save over it.

In Lovely Tools, this is the whole model. Image tools decode the image and draw it to a canvas before encoding the result. PDF tools use a PDF library to read or rebuild pages. Rendering a PDF page to an image uses the browser’s canvas as well. There is no Lovely Tools server that receives documents, because the site is static: the files that reach your browser are the same ones every visitor gets.

Where the network still appears

“No uploads” does not mean “no network requests.” The page itself has to arrive. On a first visit, your browser fetches the HTML, stylesheets, scripts, fonts, and icons. The PDF tools load their processing library the first time you use one, and the browser may fetch supporting files such as PDF fonts and character maps. These are part of the tool, not your document.

Advertising and analytics are separate. Advertising is provided through Google AdSense; depending on your location, Google’s certified consent message may ask before ad cookies are used. Analytics is opt-in, and the Google Analytics script is not loaded until you allow it. Even when ads or analytics are active, file contents and file names are not sent to either service.

The fixed requests you may see while using a tool are therefore things like:

  • JavaScript for the PDF engine, loaded once and then cached.
  • Font files and character maps needed to render unusual PDFs.
  • Page assets, web fonts, and icons.

None of those carry your document’s contents. A PDF parser running in your tab reads the file directly from the File object.

How to check for yourself

You do not have to take any site’s word for this. Browsers include the tools to inspect network activity.

  1. Open the browser’s developer tools—Network panel—while the page is loaded. In most browsers this is under View → Developer or a keyboard shortcut.
  2. Clear the request list, then choose a small test file and run the tool. A test document containing nothing sensitive is ideal.
  3. Watch for large POST or PUT requests. Uploading a file almost always produces one. A conversion that runs locally should produce no request carrying the file’s bytes.
  4. You may see script or asset requests when a tool is used for the first time. Size and type usually make them easy to distinguish: a PDF library is code, not a copy of your PDF.
  5. If you want a stronger test, load the page once, switch the browser to offline mode, and try the operation again. A genuinely local tool may still work; an upload-based one cannot.

This same test works on any online converter. It is a quick way to separate a tool that processes in the browser from one that simply avoids mentioning its upload step.

What the browser cannot do

Local processing is a deliberate trade-off, not a magic solution. The constraints are real:

  • Memory. The file and its intermediate copies live in the tab. Very large PDFs or dozens of high-resolution images can exhaust a phone’s available memory. Desktop browsers usually have more headroom.
  • Speed. Your device does the encoding. A batch of large photos may take noticeably longer than a server with dedicated hardware.
  • Format support. The browser’s canvas can read JPG, PNG, and WebP reliably. Camera raw files, HEIC in some browsers, and specialized formats need different tools.
  • Advanced PDF features. True PDF optimization requires understanding fonts, images, and vector content inside the file. Lovely Tools’s PDF compressor instead rasterizes pages, which is effective for scans but sacrifices selectable text, links, and forms.
  • No OCR. Rendering a scanned page to an image does not turn its text into searchable text. Optical character recognition is a separate, heavier process.
  • The tab must stay open. If you close it mid-operation, the working copy is gone. Download the result when it is ready.

A server is the better choice for some jobs: OCR on large archives, video transcoding, collaborative editing, or recompressing a PDF without flattening it. The point is not that local is always superior. It is that local is well suited to the everyday, single-file jobs these tools handle, and it avoids an unnecessary copy for the files people are most cautious about.

Offline use and installed apps

Lovely Tools is a progressive web app. After you visit a page, a service worker can cache its interface so it opens again without a connection. The first use of a particular tool may still need to fetch its processing library; once that has happened, the browser can reuse the cached copy. Advertising and analytics do not function offline, which is expected.

You can add the site to your home screen or install it from a compatible browser. It will open in its own window and behave more like a small application. Offline support is an enhancement—the core tools work in a normal browser tab whether or not you install anything.

A checklist for any online file tool

Before handing a sensitive file to an unfamiliar website, ask:

  • Does the page explain, in specific terms, whether the file is uploaded?
  • Can I confirm that with the Network panel using a harmless test file?
  • Does the site work at all when the browser is offline?
  • Is there an account, an email requirement, or a file-retention policy?
  • Does the result require installing an application I did not ask for?
  • Would I be comfortable if this file were temporarily stored by a stranger?

If the answers are unclear, use a local tool or a desktop application you trust. The convenience of a browser tab is real, but it is not worth losing control of a document that matters.

You can see the model in practice with the PDF merger, image compressor, or PDF to image converter. Each one works the same way: choose a file, process it in the tab, download the result.