Privacy policy

Only what sign-in, synchronisation and correspondence with the developer cannot work without:

• your email address — not in plain text, but as an irreversible transformation with a secret key: the address cannot be recovered from it, though a known address can be compared against it;
• your account identifier at Google or Apple, if you signed in that way — transformed in the same manner;
• sessions: only a fingerprint of the token in your cookie, never the token, and the time you signed in;
• codes from sign-in emails — hashed, alive for ten minutes;
• request counters, so that a code cannot be guessed by brute force;
• your correspondence with the developer, if you have used it — see its own section below;
• an unfinished sign-in: a flow started and not completed lives on the server for minutes and expires on its own;
• your top-ups, if you have topped up your recognition balance: the amount, the time and the payment identifier at the merchant who took the payment (the card number stays with them);
• a list of your devices — only the random identifier a device made up for itself and when it last checked in. Not a model, not a system, not a name: the list answers “how many are there and are they alive”, and nothing else;
• backup copies of the whole database, made once an hour and kept up to 14 days — so that a failure does not take everyone's accounts with it. What they hold and how long, see How long things are kept.

Where the server is. The server, working database and local backups run at the hosting provider Railway (USA), in its Singapore region. Working data of people in the European Union and the United Kingdom is therefore stored outside them. Encrypted external backups are stored in Cloudflare R2 under European Union jurisdiction.

Your diary lives both on your device and on the server — but on the server it is encrypted. Entries, photo previews, enlarged photo copies and weight records live in your browser's storage, and an encrypted copy travels to the server: the key to it exists only on your device. The server can see that entries were added and when — and cannot see what you ate, how much of it, or what you weigh.

We cannot read your diary either. That is not a promise to behave well; it is how the system is built — we do not have the key. Which brings the price you should know in advance: lose your diary key code along with your device and nobody can bring the diary back, us included. There would be nothing to restore it from. The code is shown in Settings, under “Sync and devices” — write it down and keep it somewhere other than your phone.

The server also keeps conflicting versions — and that is in your favour. If one entry was edited on two devices, the newer edit wins, and the one that lost is not thrown away: it stays on the server for a month, encrypted just the same, and the application can show it to you. Otherwise “it fixed itself” would be our word against your memory. We cannot read it either, of course — it is encrypted just like everything else.

Profile picture means a photo you choose or a built-in animal. It is stored on your device and goes into your backup file. It reaches the server only if you turn on picture sync: it has its own switch in the “Sync and devices” section, separate from settings sync and off until you turn it on. Then the server holds one current copy, encrypted separately with your diary key: only your devices can open it. We do not send the picture to the model or to friends. The encrypted copy is the same size whether it holds a photo or an animal: the server sees only that a copy exists, its version number and when it changed. Turning picture sync off erases that copy at once; a service record without the picture remains — the version number and the time sync was turned off — so that your other devices learn it is off. Deleting your account erases that too. Server backup copies keep erased data for up to 14 days — see How long things are kept.

Health synchronization also keeps control metadata on the server: public phone verification keys, executor leases, hashed record targets and version floors, operation states, cancellations and legacy transfer states. It contains no Health values, system record IDs, device names or notes. Control metadata is erased with the account; operation and state metadata is included in the server data file (the “Download server data” button), while public verification keys are excluded.

Settings go to the server only if you turn their sync on. Goals, profile (name, sex, year of birth, height, activity level, aim, pace, target weight, what to take into account and what you do not eat), water goal, meal shares, diary features, nutrition settings, the norm adjustment journal, quick actions, units, the share card theme and two switches — a hidden product score and a disabled open-database search — travel together, encrypted with the same key as the diary. Some of this we name separately, because it can hint at your faith or health: the ready-made set and nutrition goals (for example, “Plant-based” or “No alcohol”), the list of what you do not eat and your own words in the nutrition settings — stop words and exceptions — travel in that same copy, encrypted the same way. It is turned on by a separate switch in the “Sync and devices” section; until you do, settings are not sent anywhere. You turn it off in the same place — the server copy is erased at once, and sync is turned off on all your devices. The server sees that the encrypted copy exists, when it changed, how large it is and when sync was turned off — and not what is inside. App theme, language, reminders, the Apple Health connection and your own recognition provider key never leave the device: they belong to the device, not to you.

Your country of residence, if you chose one, is stored on this device. It travels in the backup file next to the language and is erased with your other personal settings when someone else takes over the device. It is not part of the settings sync copy, and we never work it out from your IP address or interface language. As a request field, the country code goes to our server only with a recognition request under the Snapfork key, when the “Use my country in recognition” switch is on — in transit, and it does not stay there (see “Where data does go”). The “Suggested by this device” line in the country picker is worked out on the device itself — from the system region, time zone or the region in the browser’s language settings — and chooses nothing on its own.

A backup file is still saved by you (“Save a copy”) and kept by you. It is not encrypted, and it is the only way to read your diary without the code.

We do not ask sign-in providers for your first name, surname or profile picture — only for confirmation of the email address. A name you type into your profile yourself reaches the server only inside the encrypted settings copy, and only if settings sync is on; we cannot read it.

This is about the application for iPhone. It is not in the App Store yet, and what follows describes how it will behave once it is out. The website has nothing of the kind: in a browser there is no app container and no such backup.

An iPhone backup takes app data to iCloud — that is how the backup works, not something our app does. Whether your diary goes into it is your decision, and by default it does not. You are asked on first run, and you can change the answer at any time: Settings → “Sync and devices” → “Diary in the iCloud backup”.

What is described here is the mechanism, not the outcome, and that is not evasiveness: once you have answered, the sentence “my diary is in iCloud” is true for some readers and false for others. Say yes and the backup is made and kept by Apple under Apple's rules — it is their copy, not ours: we neither see it nor can open it. Say no, or say nothing at all, and the app's folder is marked as excluded from the backup, so the diary does not travel there.

None of this touches the backup file you save yourself with “Save a copy”: that one you make and keep wherever you like. What goes into it from friends is described under Friends.

The application has a Prevention section — a reference to published recommendations on preventive check-ups, selected by age, sex and your answers. Those answers are health data, and we treat them more strictly than the diary. The section opens only after a separate consent on its intro screen; until you give it, nothing is saved.

What is kept. Where you get medical care (the country); whether you smoke, used to or never did — with pack-years and the year you quit; whether you are planning a pregnancy; which organ-specific items apply to you; “done” marks with the month and the kind of test; postponed items; the “Nothing about weight loss” switch and when you gave consent. From your profile the section reads your year of birth, sex, goal and the “What you do not eat” list — but not your weight. The section does not ask for or keep diagnoses, family history or test results.

Where. On your device, in the application's storage. In the iPhone application the answers are encrypted with a key bound to that phone: a backup can restore it to the same device, but not transfer it to another. An iCloud backup gets the answers only encrypted, and nothing can open them on another phone — there the section starts from a clean slate. In a browser the answers sit in its storage, like the diary.

To the server — only encrypted, and only if you decide so. Health answers go to the server only if you turn on their sync between devices, and then encrypted with a key that exists only on your devices, like the diary and settings. That sync has its own switch and its own consent; it is off by default and runs only inside settings sync — but turning on settings sync does not turn it on. If you said you get care in Russia, the answers do not go to the server even with sync on.

Where they never go. Not to the language model, not to friends, and not into the device details attached to a support message. They are not put into the backup file (the “Save a copy” button) by default: a separate checkbox adds them — and then remember that the file is not encrypted.

Hide, turn off sync, erase — three different actions. “Hide the section” removes it from view and leaves the answers alone. “Turn off and erase answers from server” erases the copy on the server, and your other devices erase theirs at their next sync; the answers stay on this device. “Delete answers on this device” deletes them here and, with sync on, at the next sync also on the server and on your other devices; your consent is withdrawn with them, and the section starts again from its intro screen. Deleting the account takes the server copy away with everything else; how long database backups live is set out under How long things are kept.

Photographs of meals, packaging or labels are sent to be recognised, and where they travel depends on whose key signs the request. There are two routes, and the choice is yours:

• With your own key the photograph goes from your device straight to the provider whose key you entered, bypassing our server. We do not see it and do not keep it. The provider is your choice; today the app sends the photograph to nine addresses and knows no others:
  • Google Gemini — generativelanguage.googleapis.com
  • OpenAI — api.openai.com
  • Grok xAI — api.x.ai
  • DeepSeek — api.deepseek.com
  • Qwen — dashscope-intl.aliyuncs.com
  • Mistral AI — api.mistral.ai
  • Llama Meta — api.llama.com
  • Poe — api.poe.com
  • OpenRouter — openrouter.ai
  The list is built into the app and into the browser's security policy, so the photograph cannot go anywhere but the provider you chose. Claude (Anthropic) is not on the list: the app recognises its key but sends nothing there — Claude opens browser access only with a special header that the provider itself calls dangerous, and we do not set it.
• The provider's terms apply from that point, not ours, and they are not the same everywhere. At Google, for one, they differ even between the 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. We do not retell the terms of the others: they change without us, and they should be read at the source. How to obtain a key is written in the application's settings, next to the key field.
• With the Snapfork key the photograph passes through our server, where the request is signed, and onward through OpenRouter — the service that hands it 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, cost; for someone who came through an invitation, until it counts, also the local date (see “Invitation links”). On every request we tell OpenRouter not to route through providers that retain what is sent.

The application starts on your own key and moves to ours only after yours has failed — or goes straight to ours if the model you chose does not look at photographs. That is the default, and a checkbox in settings turns it off — and then the photograph never goes through our server under any circumstances.

“Describe in words”, and recalculating from a description. When you describe a meal in text, the text you typed is sent for recognition along the same two routes as a photograph, so that the model can estimate calories, protein, fat and carbohydrates. When you ask the application to recalculate the numbers of an item from its description, the item's description — what its name field says — is sent to the model the same way. A meal description also carries its total weight, if you gave one, and the names of products from your library together with how much of each you usually have (the portion in grams), which help the model recognise what it already knows and judge the weight; the same library names, together with their portions in grams, go with a photograph of a dish as well. A meal description, like a photograph, also carries the language of the interface, so that the model names the dishes in it. The text is not stored here, just as the photograph is not: only the row of numbers remains.

Your country of residence, if you chose one. A photo, a label or a meal description also carries, together with the language of the interface, the two-letter code of your country, so that the model recognises local dishes and portion sizes. With the Snapfork key the country code goes through our server to the recognition provider; with your own key it goes straight to the provider, bypassing us. Our server only passes it on: as with a photo, the call log gets just the model, tokens and cost (for someone invited, also the local date — see “Invitation links”). Recalculating an item and sorting products into groups never carry the country, and your “What you do not eat” list never goes to the model. You can switch this off with “Use my country in recognition” in the “Photo recognition” section.

Your product search string — if you tapped “Search Open Food Facts (online)”. The application has a Products section: it searches your own products and the catalogue downloaded onto your device, and all of that happens with no network at all. When the catalogue does not hold what you are looking for, a “Search Open Food Facts (online)” button appears under the list. On that tap — and only on it — what you typed into the search field leaves your device for Open Food Facts, bypassing our server: we neither see that string nor store it. There is no autocompletion as you type and no background request: without the tap, nothing leaves.

Nothing else travels with that string: no diary entries, no photographs, no weight, no account identifier — the request needs none of them, and the application attaches none. From there the terms of Open Food Facts apply, not ours. A checkbox turns it off: Settings → Products by barcode → “Search the open database on a tap”; switched off, it removes the button itself, and nothing leaves at all. Looking a product up by the code on its pack, and searching the downloaded catalogue, never go online — neither with the checkbox on nor with it off.

The app downloads the product base from our server as a country file or, when available, a world core file; the address names the selected base (for example, /products/de.2026-09-24.csv). The name of the downloaded base and your IP address are visible to our server and to Cloudflare, which handles requests to snapfork.app. The path and IP address may appear in Railway hosting logs. Their retention depends on the providers’ settings and must be checked before release. If a country file is already installed, the app may offer to update that same file. A country file names the base selected for download, which need not be your country of residence; the world core does not name your country at all. The request goes out without the sign-in cookie. The app does not attach the download to your account. The base is downloaded only by the button in Settings; searching it afterwards stays offline.

Sign-in code emails go through the mail provider chosen by the service owner. Beyond what is listed here, nothing is passed to anyone: there is no analytics, no advertising and no third-party script on the site or in the application.

Into the letter itself the provider adds an open counter — a small image loaded from its server when the letter is opened. From that it learns that the letter was opened and when; mail clients that fetch images directly also show it the address the letter was read from. This cannot be turned off on our plan. The letter as we compose it carries no image and no link at all.

The site counts visits itself, without cookies and without anyone else's scripts. What reaches the database is daily numbers: page, language, where the visit came from. Neither IP address nor User-Agent is stored in any form — they are turned into a key with a daily salt, and the salt itself is written nowhere, so even we cannot line two days up against each other. The Sec-GPC header is honoured: with it, nothing is counted at all.

The application's settings contain a “Support” section: you can write about something broken or something missing, and get an answer in the same place. This is a conversation rather than a form — which means it is stored on the server: otherwise there would be nowhere to answer.

What is stored is the text of your messages and the developer's replies, attached to your account. They are read only by those whose confirmed addresses the service owner has put on the developer list: the list is closed, it lives in the server's settings, and nobody else sees the correspondence. Neither an email address nor a name sits next to it — the server does not hold them in plain text anyway, and the conversation is held with a diary, not with a person.

Device details are attached only if you tick the box, and before sending you are shown exactly the text that will travel: the version of the application and of the database, operating system and browser, language, window size, the screen you are writing from and the code of the failure if you came from one, how many entries and weigh-ins you have as plain numbers, whether the device was online, whether the app was opened from its icon or in a browser tab, whether debug mode is on and whether a provider key is set — “yes” or “no”, never the key itself. Not a single diary entry, photograph, weight record or profile field goes there.

The notification email that reaches the developer contains neither the text of the message nor your identifier: only “there is a new message in the thread”. The contents of the correspondence never reach the mail provider and never appear in the server logs.

The application can give you a permanent invitation link. Whoever signs up through it gets recognitions with our key as a gift while the link has gifts left, and you get yours once they have recognised food with the Snapfork key on two different days (counted by their own local calendar), until the reward limit is used up. Nothing else changes: nobody gains access to anyone else's diary.

For this, the app sends the device’s local date with every recognition by the Snapfork key. It is kept only for someone who came through a link — until the invitation counts and as long as the inviter has not deleted their account — and for no more than 30 days. A date that exists in no time zone is rejected: such a call, like a call without a date, is counted by the time zone of that person’s other dates — or, without any, in universal time. If their dates disagree (travel, devices in different zones, a clock change), that person’s whole count goes by universal time.

What is stored is the fact that one account arrived through another's link: which link, when, and whether the reward has been earned. That is a record about a connection between two people, so it is kept to the minimum and shown to nobody: the person who invited sees numbers only — how many came, how many of them have recognised food with the Snapfork key on two different days, how many recognitions were received and how many gifts the link has left. Not a name, not an address, not a moment of signing in. We do not say who accepted, because that would be telling a third party that a particular person started keeping a food diary.

The link itself carries a code and nothing about you. Opening it is counted by the visit counter as its own campaign — the label only: the code never reaches the counter, otherwise the daily numbers would turn into a table of whose links work.

Deleting an account removes the link and the record of where that account came from; the reward entries stay with the account identifier stripped, because the limits on how much can be given away are counted from them.

The “What the server holds about you” file carries your links, revoked ones included, the record of how and when you arrived and whether the reward was earned, how many people came through your links and how many of them counted — as numbers only — your reward entries and how many gifts your link has left. Who invited you and who came through your link are not named in the file.

Top-up entries behave the same way: deleting an account leaves them in place but stops them naming anyone. The reason is not bookkeeping but you — a bank can dispute a payment a month after the account is gone, and with no amounts left there would be nothing to answer such a dispute with. Any remaining balance is burned on deletion, and that is written as its own entry: money for which no service was rendered stays visible as exactly that, instead of dissolving into revenue.

If you are connected with a friend and have allowed them to see your week, your week leaves your device — derived from your diary, exactly two facts per day for the last seven days: whether you logged anything at all and, if you shared that separately, whether you stayed within your own goal. Plus how many days in a row you have logged. Not what you ate, not how many calories, not your weight — none of that goes into your week, at any level of sharing. Besides the week, a friend gets only what you send yourself: a note from a fixed set of cheers, or a food card — see below.

You see a friend’s week only if you have shared your week with them, and their goal fact only if you have shared your goal too; on your friend’s side our app shows them exactly as much about you as it shows you about them: your device shows a friend’s week only with mutual consent. Your goal fact travels to your friend encrypted whenever you have shared your goal with them, but it is shown to them only if they have shared their goal with you too. Consent is asked per friendship and per level, and we record which text you agreed to: if the meaning of that text changes, we ask again rather than quietly extend it. You can undo it any day, and there are two buttons: “stop sharing” keeps the friendship, “delete friendship” removes the connection and erases what each of you saw of the other.

A food card leaves only when you send it yourself. On the friends screen you can send a friend a food from your library. The card carries its name, the numbers per 100 g — calories, protein, fat and carbohydrates — the barcode if there is one and where the numbers came from; sugar, saturated fat, salt and fibre only if they come from a label, a barcode scan or the catalogue. It carries no weight, no date and nothing about when or how much you ate. It travels encrypted the same way as a note, at the same length and by the same route, so the server cannot tell a card from a note. Your friend decides what to do with it: nothing reaches their diary or library until they save an entry with it, and a card nobody took disappears after seven days. You can send one friend at most five cards a day, counted back from the moment you send rather than from midnight. “Take back” erases the encrypted card on the server, and the card leaves your friend’s screen at their next exchange; if they have already added it, it stays with them. Deleting the friendship erases the cards between you on the server together with the connection.

There is one exception — the backup file you save yourself: it is not encrypted, and it carries your friend’s week — exactly what you saw about them. Replies and food cards are not in it. Deleting a friendship erases what was seen both here and on the device, but it does not reach the files you have already saved: what happens to those is up to you.

Blocking. The “Block” button on a friend’s card ends the connection at once — like “delete friendship”, together with everything sent between you in both directions — and stops the two of you from inviting each other again: no link between you will be accepted any more. For this the server keeps who blocked whom, and since when — no reason and not a word from you — until you unblock under “Blocked” on the same screen, or until one of you deletes their account. We do not tell the other side: they see what they would after “delete friendship” — the friendship has ended, and your link simply does not work for them, like an expired one. Unblocking does not bring the friendship back: a connection starts only when one of you accepts the other’s link. The “What the server holds about you” file carries your friends as the server holds them: your public key, your connections with the day each began, your invitations, your bars if there are any, and what was sent from you and to you — encrypted, so only your device with your friends or the friend’s device can open them. A friend appears in the file as an account identifier, not a name; their key, what they sent to anyone else and bars placed on you are not in it, and neither are levels and consents — those are kept on the device.

We cannot read any of it — provided the key is genuine. The contents travel encrypted with a key we do not have, every encrypted item is the same length, and even the size gives away nothing about how many days are inside. But some things we do see, and we say so plainly:

• who is connected to whom, and since when;
• your public key;
• that you have a friends key vault, and when it changed; while a request to reset your friends is pending, the request itself and when it takes effect, plus a second vault ciphertext of the same fixed length;
• when you open the friends screen — that is when your device collects its inbox and, if you have shared your week, sends it — and when a note or a card was sent or taken back; and, if your friends are on several devices under the shared key, when you took a friend’s product card or turned it down;
• that invitations exist, and how many.

What we do not see: what is inside, how much is in there, and what you called your friend on your own device. Your friend sees when your week was last updated — that is the last time you opened the friends screen.

That caveat about the key is not a figure of speech. The keys you exchange travel through our server — which means that, in theory, we could swap them. You can check this: thirty-two digits computed from both public keys must match for you and your friend. We offer that check rather than require it — and until you have made it, you are trusting the server to have handed over the real key. The friendship screen always shows whether it has been verified.

If you sync your diary, the private friends key travels between your devices the same way the diary does: in the friends key vault, encrypted with your diary key, which we do not have. Your permissions, verifications and names for friends are kept there too. So your friends are available on every device where your diary key code is entered, revoking a permission on one device applies to all of them, and verification is shared: you don’t need to compare the digits a second time. A verification covers your friend’s whole key, and if a verified friend’s key changes, your week doesn’t go to them until you compare the digits again. Until your friends use the shared key, the friends screen offers the move to it: with no friends and no open invitations you can do it at any time, but once you have friends or an open invitation, the move changes a key others already rely on — as does moving your friends here — so either is possible only right after signing in. When you issue a new code, you can change the friends key as well, and in the account settings sign out on other devices (also only right after signing in): that is how a lost device is cut off. The order is: sync your other devices, issue a new code, then sign out on other devices. A new code shuts the lost device out of new diary entries on the server, a friends key change out of new friend weeks, and signing out cuts its access to the server; what is already on the lost device stays there. Your friends will then see a new key and can compare the digits again. When the friends key changes, the server also erases what was waiting for you under the old key — friends’ weeks, notes and product cards: the new key cannot open them, and your friends send new ones. If the code is lost, you can reset your friends with the “Reset friends” button — right after signing in (with the code from your email, or with Google or Apple). Resetting needs a device with your diary key code; if that device has no code either, first create a new one — that is a new diary key. The reset takes effect after a day unless, in that time, the app opens online on a device with your code: such a device withdraws the request by itself, even if you never open the friends screen — which means you still have the code. After the reset, the key changes, verifications are cleared, and you will need to allow sharing your week again. The private half of the friends key never goes into your backup file; on the device itself it lies in the vault snapshot, in the same device database as the diary key, and a device backup that you let your diary into carries it along with the diary key.

Without sync or without the shared friends key, the key that encrypts your week is kept on your device and never travels — not to us, not into your backup file. So on a new device, friendships have to be confirmed again. Friends live on one device at a time, and the server changes your key only while you have no friends or open invitations yet, or when you move them (only right after signing in) — with a backup on a new, still empty device or the “Move here” button: they stop on the previous one (“Bring back here”), and sharing your week needs to be allowed again.

How long things last: an unaccepted invitation lives 30 days and works once; your week sits on the server until the next one and is erased at once when a friendship ends or you move to a new device — once a new, still empty device restores your backup or you confirm the move on the friends screen — and, with the shared friends key, also when you move to it, when the friends key changes with a new code, and when a reset takes effect; notes live seven days; the friends key vault stays until you delete your account; the connection lasts until it is ended or the account is deleted. Social features are not offered to anyone whose profile says they are under 16.

You can have no more than 50 friends, and that ceiling is ours rather than the product's: the longer the list, the more connections the server knows about. Invitations are capped for the same reason — five live at a time, ten a day.

Exactly one on the whole domain: the sign-in session. It is technical, is set only when you sign in, lives up to 180 days from the last sign-in, and is visible to nothing but the application. Before you sign in there is none — and afterwards it travels with every page here, this one included, because the site and the application answer at one address. There is no banner because consent is not asked for the cookie without which signing in cannot work, and there is nothing else to ask about: no analytics, no advertising.

Each purpose has its own legal basis under the GDPR (Articles 6 and 9):

• Performance of a contract (Art. 6(1)(b)) — what the service you ask for cannot work without: your account, sign-in and code emails, the encrypted copy of your diary, recognition with the Snapfork key together with the language and country, downloading the product database, correspondence with the developer, invitation links and the mechanics of friendship: the connection, keys, the friends key vault, delivery of encrypted messages, bars on repeat invitations, and notes and food cards — you send those yourself, and they need no consent to share your week.
• Consent (Art. 6(1)(a)) — settings sync: it is switched on separately and can be withdrawn at any time with the same switch.
• Explicit consent (Art. 9(2)(a)) — health answers and their sync, withdrawn with the section’s buttons, and your week for a friend: each friendship and each level of sharing needs its own consent, withdrawn with the “Stop sharing” button.
• Legitimate interests (Art. 6(1)(f)) — database backups, hosting logs, the visit counter and anonymised top-up records kept for payment disputes. You can object to this by writing to the address below (Art. 21).

You can also complain to the data protection supervisory authority of your country.

The model call log is stored on the server for as long as the account exists.

The server data file also includes your model call log: day, time, request type, model, payment source, status, tokens and cost in US dollars, plus an invited person’s local date while it is stored. The log contains no photos, request text or model responses; the IP address hash is omitted from the file.

Session — up to 180 days from the last sign-in. Email code — 10 minutes. Daily counter numbers — indefinitely, but they contain nothing about a person. Account — until you delete it. Correspondence with the developer — exactly as long as the account: it goes together with it and has no separate term. We chose not to name a separate term deliberately: it would be a promise to erase on a schedule, and there is no schedule — so the promise would be false from the first time anyone checked.

An invited person’s local date — no more than 30 days; it goes sooner once the invitation counts or the inviter deletes their account (see “Invitation links”).

Diary entries on the server — as long as the account lives. They have no separate term, and that is a decision, not an omission. The server keeps an encrypted copy of the diary for the sake of your second device — and a copy that vanishes by itself is of no use to a second device: it would have nowhere to get back what the server forgot, and the diary on it would quietly turn out shorter than on the other one. Entries go together with the account and only with it: delete it, and the encrypted copy of the diary leaves the server's database at once, and its backup copies as they rotate out — how soon is said at the end of this section. The diary on the device itself remains yours and is erased separately.

The thirty days named below are not about the entries themselves, and the two terms should not be confused. Thirty days is the life of photo previews (both on the device and on the server) and of enlarged photo copies on the server and entry versions that lost a sync conflict. All three lie BESIDE an entry rather than instead of it: what goes is a picture or a previous draft of the line, while the entry itself stays where it is. The server terms count in the server's working database; in its backup copies a picture or a version can outlive them by up to 14 days — see the last paragraph of this section.

Meal photo previews — 30 days. The application keeps a small copy of the picture beside the entry and deletes it from the device thirty days after the picture was taken. The entry itself stays: only the picture goes. We do name this term, precisely because here a schedule exists — the sweep runs every time the application opens and immediately after a backup is restored — and you can check it by opening an old day. The original camera file is not kept in the diary. Alongside this preview, the entry keeps a compressed enlarged copy on the device for the same term. A backup file you save includes that copy unencrypted.

A photo in Later — on the device, no longer than 30 days. A photo you put in Later to be recognised afterwards stays on the device in full, not as a preview: until it has been recognised and you have saved the entry, and no longer than thirty days after it was taken. When the term runs out the photo is deleted, while the reminder of the meal stays, so you can record it by hand. It leaves the device only at the moment of recognition — by the same route as any other photo (see Where data does go). The full photo sent for recognition is not kept on our server. If you save an entry, its preview and compressed enlarged copy are stored separately, encrypted with your key, as described below.

On the server the preview lives by the same term — no longer than thirty days. It travels there encrypted, along with the diary, so that it can appear on your second device; we cannot open it, any more than we can open the entries. The server counts the term from the day the picture arrived, not from the day it was taken: it does not know the day it was taken — that is inside the ciphertext. The sweep runs at server startup and every hour, up to one hour before expiry so that retention never exceeds 30 days.

Enlarged copies of meal photos — on the server for up to 30 days. If an entry has one, the app sends it separately from the preview, encrypted with your key. The server sees only ciphertext; the picture address is inside the encrypted entry. Another device fetches the copy when you open the picture. The server deletes it on its hourly sweep, counting from arrival, and immediately when you delete your account. Your server data file includes it as the same ciphertext.

Entry versions that lost a sync conflict — no longer than thirty days. When you edit an entry you replace its previous version; the server does not throw that previous one away at once but keeps it aside — so that “it fixed itself” is not our word against your memory. You can see them and bring them back in the application, in the conflicting-versions card. They lie there encrypted, like the entries: we cannot open them either. The sweep runs at startup and every hour, covering the next interval — and that is why we name the term here.

Such a version can go sooner than the term, and it is more honest to say so plainly: per entry the server keeps at most twenty of them, and the twenty-first displaces the oldest. That is an engineering limit against runaway code, not a promise to keep twenty. The current version of an entry is touched by neither the term nor the limit: it is your diary, and it goes only together with the account.

Server backups — up to 14 days. Once an hour the server copies its whole database — insurance for the day a failed disk or a broken update would otherwise take everyone's accounts with it. Copies from the last 48 hours are kept one per hour, older ones one per day, and a copy older than 14 days is deleted at the next hourly rotation. Copies are deleted only by a running server: while it is switched off, every copy stays, and once it is back the expired ones go at once. One caveat: the newest copy always stays — even when expired, if new copies have stopped succeeding — until the next successful one, because an old copy is more use than an empty shelf. A copy holds exactly what the database held at that hour, and in the same form. What is encrypted with your key — the diary, previews, settings, the profile picture, conflicting versions, the friends key vault — stays encrypted in the copy, and we have no key to it; what the server sees openly — the correspondence with the developer, who is friends with whom — it sees in the copy as well. This is why every term above is a term in the working database: whatever was erased there — by the sweep or together with the account — stays in the backup copies no longer than 14 days after that, save in the cases above. Fourteen days is an upper bound, not a promise to keep: a copy can go sooner, for instance when the disk runs short of space.

External backup — planned expiry after 35 days. Once a day, the server sends a database backup to Cloudflare R2 under European Union jurisdiction. The entire archive is encrypted before it is sent, using a separate backup key. The planned expiry period is 35 days. After expiry, R2 deletes objects asynchronously, so actual storage may last longer. Data erased from the working database remains in external backups until those backups are actually deleted.

As of 9 October 2026, the external store also contains a backup from 2 October 2026 created before encryption of the entire archive was enabled. This older copy is subject to the same planned expiry rule.

In the application: settings → “Delete account”. That erases the account, all of its sign-in methods, all sessions and the whole correspondence with the developer; for Apple sign-in it also revokes access on Apple's side. What the server kept for synchronisation goes with the account too: the encrypted copy of your diary, the photo previews, the encrypted copy of your settings, the encrypted profile picture, the journal of conflicting versions and the list of your devices — none of it is left in the server's database. So do your friend connections, your public key, the friends key vault, what was sent between you and your friends, your friend invitations and any bars on repeat invitations. The hourly backup copies still hold it for up to 14 days, in the same form, and then it is gone from them too (provided the server was running and new copies were succeeding); how the copies work is described under How long things are kept. The daily numbers of the visit counter stay: they contain nothing about a person, and they cannot be removed per account, because there is no account in them. The diary on your device is erased by a separate button — it is yours alone, and we will not decide its fate for you.

This policy changes along with the service; the date at the top of the page is the date of the last edit. Substantial changes are announced here rather than by email: the server keeps no address it could write to — only a fingerprint of one.

The data controller — whoever decides what is stored here and answers for it — is a private individual, not a company: Snapfork has no legal entity behind it. That individual is Oleksandr Trifonov. Everything about the service, including requests concerning your own data, goes to the address below. What that arrangement means in practice is set out on the page “Who is behind Snapfork”.

Questions, access to your own data and deletion — through the questions page or by writing to hello@snapfork.app.