How It Works

Almost every tool on this site processes your file inside your own browser rather than on a server. That is a genuine and checkable difference from the usual online converter, and it is also narrower than the phrase is often made to sound. This page explains what the design does, what it does not do, and how to verify both for yourself in a few minutes.

What “runs in your browser” means

When you pick a file, the browser reads it into the memory of the open tab. The page's own JavaScript, and in some cases a WebAssembly engine running alongside it, then does the work there: rearranging PDF pages, re-encoding an image, cutting a video, hashing a string. The result is assembled in the tab and handed to you as a download.

The usual model is the opposite: your file is sent to a server, a program there processes it, and the output is sent back. That means a copy of your document exists on somebody else's machine, at least briefly, and often in their logs and backups too. Here, no such copy is ever created, because the file is never transmitted. There is no upload endpoint for tool input on this site.

What this genuinely protects against

No upload: your document is not transmitted across the network to be processed, so it cannot be intercepted in transit or inspected at the other end.
No server-side copy: there is no file on the operator's infrastructure, so there is nothing to be exposed in a breach of it, nothing to be shared with a third party, and nothing that could be handed over in response to a request.
No retention: nothing you process is stored anywhere by this site, in any form, for any period. Closing the tab is the end of it.
No account, no profile: there is nothing to sign up for, so there is no record linking a person to the tools they used.

These are properties of how the site is built, not undertakings about how it will behave, which is why the section below on verifying them exists.

What this does not protect against

This is the part most pages like this leave out. Local processing solves one problem well and leaves several others exactly where they were.

The page still comes from a server. You load this site over the network, so the request for the page itself reveals your IP address and browser to the hosting platform, and it appears in ordinary server logs. Local processing changes what happens to your file, not the fact that you visited.
Analytics and advertising still operate when you allow them. If you grant the analytics or advertising category in the consent banner, Google's scripts load and behave as Google's scripts do, including setting their own cookies. They do not see your file, but they do see your visit. Declining prevents them from loading at all.
CDN downloads reveal your IP address. The video, audio, GIF and OCR tools fetch their processing engine from a public CDN on first use. Your media is not part of that request, but the request tells the CDN operator your IP address and user agent, and that you asked for that particular engine.
A compromised device is still compromised. If malware, a hostile browser extension or another person with access to your machine can read what is on your screen or in your browser's memory, processing locally does not help. It moves the work to your device; it cannot make your device trustworthy.
Anything you send deliberately is sent. The contact form transmits what you type and stores it in a Google Sheet the operator reads. That is described in the privacy policy.
It is not a legal compliance status. Not receiving your files removes a large category of risk, and it is not the same thing as a certification or an audit. No such claim is made here.

Every network request the tools make

Beyond loading the page itself, this is the complete list.

Video Trimmer, Audio Converter, GIF Maker: download the FFmpeg WebAssembly engine, roughly 30 MB, from unpkg.com on first use. Your media file is not uploaded; the engine is downloaded.
OCR PDF: downloads the Tesseract engine and its English language data, roughly 15 MB, from the jsDelivr CDN on first use. Your PDF is not uploaded.
Device Info: calls this site's own /api/ip route, which reads the IP address from your request headers and returns it to you. It is not stored by the application.

Two things that could easily have been third-party requests are not. The face-detection models used by the privacy blur tool are served from this site's own domain, and the fonts are self-hosted, so no request goes to Google Fonts while you browse.

How to check any of this yourself

You do not have to take any of the above on trust. Your browser will show you every request the page makes.

Open a tool page, then open developer tools — F12, or Ctrl+Shift+I, or Cmd+Option+I on a Mac — and select the Network tab.
Reload the page so the recording starts from the beginning.
Pick a file and run the tool exactly as you normally would, then download the result.
Read the list of requests. Sort by size, and look for anything leaving your machine while the tool works.

What you should see is the page and its scripts loading, then nothing further while the file is processed — no request carrying your file, and no request whose size is anything like the size of your file. On the four engine-backed tools you will see a large download from unpkg.com or jsDelivr, which is the engine arriving; the direction is inward. If you consented to analytics or advertising, you will also see Google's scripts and their calls. If you ever see a request uploading your file, that is a bug worth reporting through the contact form.

A second check: after the page has loaded, disconnect from the network and use a tool that needs no engine — merging PDFs, or formatting JSON. It keeps working, because there is nothing left for it to ask a server for. The site's source is also published at github.com/vishalanand1997/privaquicktools, so the behaviour can be read as well as observed.

Common questions

Do the tools work offline?

Once a page has loaded, most of them do, because they make no further network requests. The exceptions are the tools that must first download a processing engine — Video Trimmer, Audio Converter, GIF Maker and OCR PDF — and Device Info, which asks the server for your IP address.

Is there a file size limit?

The site imposes none, because there is no upload. The real ceiling is your own device's memory, since the whole file is held in the browser tab while it is processed. Very large scanned PDFs and long videos are the first things to fail, usually by making the tab unresponsive.

Is it safe to paste an API key or a token into the developer tools?

The input never leaves the page: there is no request carrying it anywhere, and you can confirm that in the Network tab. Two things are still worth knowing. Your operating system's clipboard history may retain what you copied, and any production credential that has been pasted into a browser at all is usually worth rotating.

Why does the first run of the video or OCR tools take so long?

They download a WebAssembly engine before any work can begin — roughly 30 MB for FFmpeg, roughly 15 MB for Tesseract with its English language data — and then compile it. Later runs in the same session reuse what was already downloaded.

What happens to my file when I close the tab?

It is gone. The file was held in the tab's memory, and closing or reloading the tab discards it. Nothing is written to a server, and nothing is cached for later. That also means unsaved work cannot be recovered.

Where to go next

Each tool page states how that specific tool handles your data and where its output can be wrong. The privacy policy covers everything the site touches, the disclaimer covers the limits of the results, and about explains how the site is maintained.