Privacy and network access

FileVerdict sends no telemetry, no analytics and no crash reports. There is no account system. Your media files, their names and their contents do not leave your machine except where the table below says otherwise.

Everything the app can contact

Host	When	What is sent	Avoidable?
Licensing server	Launch, activation, periodic re-validation	Licence key, device fingerprint	No — this is how licensing works
OMDb, through FileVerdict’s licensing server	Rename lookup — the default, no setup needed	A title guessed from your filename, and a lookup pass that does not identify you. Not your licence key or device. See below	Yes
TMDB	Rename lookup, only if you paste in your own key	A guessed title, plus your key	Yes
GitHub	Update check, shortly after launch or manually	Your IP and current version	Yes

That is the complete list.

Title lookups do not say who you are

A lookup carries a title guessed from one of your filenames, so a record of your lookups would be a list of what is in your library. FileVerdict is built so that no such record exists.

By default, lookups go to FileVerdict’s own server, which asks OMDb and passes the answer back. That keeps FileVerdict’s OMDb key off your computer, where anyone could copy it out of the app.

The lookup carries no identity. When the app checks its licence it is given a lookup pass, good for three days. A lookup sends that pass and the title, and nothing else: not your licence key, your email or your device. The pass holds an expiry and a code that changes every day, and nothing stored on the server can turn that code back into a licence.
Nothing about a lookup is logged. No title, no query and no address. Request logging is switched off on the server.
OMDb is sent the title alone, from FileVerdict’s server, so OMDb does not see your IP address.
What is kept is a rough daily count of lookups per pass code, deleted after a week, so one licence cannot use up the lookups everyone shares, and OMDb’s answer to a lookup, cached for a day so the same title is not asked for twice. A cached answer has nothing about who asked.

FileVerdict runs that server, so this rests on how it is built, and the code that does it is described here so you can hold us to it. If you would rather no title went near FileVerdict’s server at all, add your own free TMDB key: lookups then go straight from your computer to TMDB.

Work offline

Settings → General → Work offline stops every optional request in that table: metadata lookups and update checks.

It is enforced in the core of the application at each outbound call, not by hiding a button in the interface. A test reads the source and fails the build if any new network call is added without going through that check, so a future feature cannot quietly reintroduce traffic.

Everything the app actually does to your files — scanning, classification, renaming, remuxing, encoding — needs no network at any point. Renaming still works offline; it falls back to reading the title out of the filename instead of confirming it against a provider.

What is deliberately not sent

No file paths, sizes or library contents. No usage statistics, feature counters or error reporting.

Fonts and bundled tools

Fonts are bundled in the application and never fetched from a CDN. ffmpeg and MKVToolNix are bundled too. Nothing is downloaded to make the app work, and no font, analytics or asset host is contacted at startup.

One install-time exception, on Windows

FileVerdict draws its interface with a rendering engine the operating system already has, rather than shipping one of its own. On Windows that is WebView2 — the app does not open or use Edge, it renders into its own window. This is why the download is tens of megabytes rather than hundreds.

Linux and macOS builds will use those platforms’ own system engines the same way, for the same reason given below.

WebView2 ships with Windows 11 and has reached Windows 10 through Windows Update since 2021, so virtually every machine already has it. On a machine that does not, the installer downloads it from Microsoft. That happens at most once.

Bundling a private copy instead would add around 127 MB and, worse, would stop receiving Microsoft’s security updates — leaving the component that renders the interface permanently unpatched. Using the system engine means Windows keeps it patched.

What is stored locally

Everything FileVerdict keeps lives in your operating system’s standard app-data folder, never inside the installed application:

Platform	Folder
Windows	`%APPDATA%\FileVerdict\`

Linux and macOS builds will use their own platforms’ standard locations, and this table gains a row for each as those ship.

It holds:

your settings and preferences
saved presets
encode history, which includes file paths
the diagnostics log, in which paths are reduced to filenames only, so a log you send with a support request is not an index of your media library
the signed activation file from licensing

Your TMDB key

The TMDB key is one you register and paste into Settings. It is yours, not the app’s, and FileVerdict treats it that way: rather than writing it into its settings file, it hands it to the operating system’s own credential store — the Credential Manager on Windows, and the Keychain or Secret Service on macOS and Linux when those builds arrive.

The reason is that a settings file is not a private place. Anything running as you can read it, and backup and sync tools copy it wholesale, so a key put there travels considerably further than the person who pasted it intended.

The app never displays a saved key back to you — Settings only says whether one is stored. On a machine with no usable credential store it falls back to saving the key the way any other setting is saved, rather than refusing to save it at all, and records that it did so in the diagnostics log.

None of this is transmitted anywhere. Uninstalling does not remove it; delete the folder by hand if you want it gone.