No network calls
The application ships no HTTP client. There is no endpoint for it to report to.
Local-first
StegoPixel is built to be trusted with sensitive material — that is the entire point of the product. So the architecture had to match the promise. Here is exactly what that means, in detail you can check.
The application ships no HTTP client. There is no endpoint for it to report to.
Nothing to sign up for, nothing to sign in to, no licence server to phone home.
No usage analytics, no crash reporting service, no “anonymous statistics” opt-out to find.
No sync, no remote processing, no fallback upload when a task looks expensive.
This is the part that usually turns out to be untrue in other products, so it is worth being exact. In the current StegoPixel codebase there is no HTTP client, no web request, and no analytics or telemetry library. Analysis, AI detection, hashing, steganography, reporting and database work are all local operations.
The only outbound URLs the application can produce are map links written into a geo-tag report:
| URL | When it is produced | When it is contacted |
|---|---|---|
openstreetmap.org | When a report records coordinates found in an image. | Only if you click the link. The app itself never requests it. |
maps.google.com | Same — as an alternative map reference. | Only if you click the link. |
Everything else the app opens — a file, a folder, an exported report — is opened through your operating system's default handler, which is you asking Windows to show you a file, not the app uploading one.
Run the app with your network disconnected, or watch it in Windows' own resource monitor or firewall. Every feature — including detection and C2PA manifest parsing — keeps working, because none of them depend on a remote service. That is the practical test, and it is available to anyone.
Everything StegoPixel stores lives under your own Windows user profile, in a single folder. Nothing is written into the application's install directory, and nothing is written anywhere else.
| What | Purpose |
|---|---|
settings.json | Your preferences — theme, language, cleanup profiles, steganography defaults, hashing algorithms. |
stegopixel.db | The local SQLite database: your saved workflows and their execution history. The schema also defines tables for an image index and collections, which the current pre-release build does not populate. |
privacy_profiles\*.json | Any custom cleanup profiles you define. |
signing-keys.json | Signing key pairs, if you create any — see the note below. |
| Metadata templates | The reusable tag sets you save for repeated application. |
logs\ | Daily-rotated local diagnostic logs, retained for a week. They are never transmitted. |
Because all of it is a normal folder in your profile, it is covered by whatever backup, encryption or profile-roaming you already use. Deleting the folder resets the app; there is no server-side copy that would survive.
Image signing needs a private key, and StegoPixel stores its key pairs in signing-keys.json inside that folder. If you set a passphrase the private key is encrypted; if you do not, it is stored base64-encoded rather than encrypted. Treat that file the way you would treat any private key: keep it out of cloud-synced folders you do not control, and do not share it. This is worth stating plainly because a key file is the one item in the data folder whose exposure has consequences beyond losing your settings.
When you ask StegoPixel to encrypt a hidden payload, it uses AES-256-CBC with the key derived from your passphrase through PBKDF2 using SHA-256 at 100,000 iterations. These are standard, well-understood primitives — nothing bespoke, and nothing that depends on a service being reachable.
Steganography hides the existence of a payload. Encryption protects the contents if the carrier is found anyway. You want both: an unencrypted payload inside an image is only as private as the fact that nobody looked. Conversely, encryption does not make an obviously suspicious file less suspicious.
Passphrase strength still matters. PBKDF2's iteration count raises the cost of guessing, but it does not rescue a weak passphrase — the same is true of every tool built on these primitives, including password managers.
StegoPixel never modifies your original images unless you explicitly apply changes. The defaults are chosen so that a mistake is recoverable.
StegoPixel is being prepared for distribution through the Microsoft Store as a packaged desktop application. That changes a few things worth knowing:
%LocalAppData%\StegoPixel and is untouched by install, update or uninstall of the app itself.Being precise about a privacy claim means being precise about its boundaries too.
The FAQ covers the practical questions, and the About page explains how to reach us. If a claim here turns out to be wrong, that is a bug worth fixing — the whole point is that it should be checkable.