Where your food diary actually lives
On your phone. Not as a slogan — as the place the entries are physically written to. A copy travels to the server as well, sealed, and nothing there can open it: the key stays with you.
What leaves the device, and in what form
Entries, portion weights, your weight log and the small photo previews are written to your browser's own storage, and a copy travels to our server sealed: the key exists only on your device. The server cannot show the contents to anyone — not because we promised, but because it has no key. A backup is a file you export yourself and keep wherever you like.
The practical consequence is worth stating plainly, since it is the same property seen from the other side: lose your recovery code along with the device and nobody can bring the diary back, us included. There would be nothing to decrypt it with.
What does leave the device
Two things, and both only when you act: the photograph of the meal and your product search string.
The search string — only if you tapped “Search the open database”. The Products door searches your own products and the catalogue downloaded onto the device — with no network. When the catalogue does not hold what you need, a button appears under the list, and on that tap what you typed goes to Open Food Facts straight from your device, bypassing our server. No autocompletion as you type, no background requests: without the tap nothing leaves, and nothing travels with the string — not the diary, not the photographs, not any identifier. A checkbox in settings (Products by barcode) turns it off, and then the button is not there at all; looking a product up by the code on its pack never goes online, whichever way the checkbox is set.
The photograph of the meal. Where it travels depends on whose key signs the request, and that is your choice in the app:
- With your own key the photo goes from your device straight to the platform whose key you entered, not through our server. We do not see it and do not keep it. There are ten platforms whose keys the app understands and nine addresses a photograph can reach; they are named one by one in the privacy policy, and it knows no other addresses.
- With the Snapfork key the photo passes through our server, because the request is signed there, and onward through OpenRouter — the platform that hands the request to the model provider. It is not stored here: not the file, not a copy in a log. What remains is a row of numbers — model, tokens, what it cost us. On every request we tell the platform not to route through providers that retain what is sent — that is part of the request, not a promise in prose.
The app starts on your own key and moves to ours only after yours has failed: quota spent, key revoked, platform silent. That is the default, and a checkbox in settings turns it off — then a failure of your key simply means no recognition, and the photograph never leaves the platform you chose. Every photo recognised on our key says so on screen.
After that the platform's terms apply, not ours. At Google, for one, they are not even the same on both tiers of a single key: on the free tier it reserves the right to use what you send to improve its products; on the paid tier it does not. Other platforms have their own terms, to be read at the source. Whose key to enter, and on which tier, is your choice — and it is the single most consequential thing to understand before photographing your food.
What the server does hold
More than a sign-in needs, and it is better said plainly. For signing in: your email address as an irreversible transformation rather than plain text, a session fingerprint, and codes from sign-in emails under a hash for ten minutes. For the diary: its sealed copy, the photo previews and the conflicting versions, and your settings if you turned their sync on — all of it sealed with your key. Beyond that: your correspondence with the developer, top-ups of the recognition balance, the list of your devices, friends and invitations if you use them, and hourly backup copies of the database. The privacy policy is the single authoritative copy, and it lists all of this in full, with how long each thing is kept.
Things that are not here
- No cookie banner. There is exactly one cookie here — the one that keeps you signed in; without it signing in does not work, and nowhere is consent asked for that. Nothing is set for analytics or advertising.
- No third-party analytics, no advertising pixels, no chat widget.
- No web fonts from a CDN — the text you are reading is set in your own system's font, which costs no request at all.
These are checkable rather than promised: open the developer tools and watch
the network tab while this page loads. One request there is ours, and it is
easier to name it here than to let you find it: a beacon to /hit
that counts the visit without cookies and without anyone else's code. What it
records, and what it deliberately does not, is written out on the
privacy page.