Privacy

The short version: there is no third-party analytics, no tracking, no advertising, no cookies and no accounts on this site. But recipe text is sent to a server to be read — that is how the ingredient parsing works — and the site does count, anonymously, which foods recipes are made of. Both are worth being precise about.

Everything that leaves your device, in one table

What	Where it goes	What is kept, and for how long
Recipe text	This site’s server, then Anthropic	The parsed ingredient list, keyed by a hash of the text — a fingerprint, from which the text cannot be recovered. The text itself is never stored. Kept indefinitely.
Ingredient search terms	This site’s server, then USDA	The food record. Public nutrition data. Kept indefinitely.
Photos of a recipe	This site’s server, then Anthropic	The transcribed ingredient list, keyed by a hash of the image. The image is never stored. Kept indefinitely.
Photos of a nutrition label	This site’s server, then Anthropic	The label’s numbers, as a public product record. The image is never stored. Kept indefinitely.
Which foods a recipe used	This site’s server	Counts only, no recipe text and no identifier. Kept indefinitely.
A suggestion you send	This site’s server	The message, an optional email address if you give one, and which page you sent it from — see the suggestion form.
Servings, edits, swaps, saved recipes	Nowhere	Computed and kept in your browser.

The rest of this page is the detail behind that table.

What gets sent, and where

Your recipe text goes to two places.

This site’s own server (/api/parse), which forwards it to Anthropic’s Claude API to be broken into structured ingredients. Anthropic processes the text to produce the response. Anthropic does not train its models on API inputs; their retention policy is described in the Anthropic privacy policy.
Individual ingredient search terms (/api/foods) — words like tomatoes, canned — which are looked up against USDA FoodData Central. This includes anything typed into the search box in the “Change” panel on the results page, which is the same lookup asked by hand. Only the words are sent; nothing identifies who asked, and the term is not stored against you.

What is stored on this site’s server:

The parsed result of each recipe, keyed by a hash of the text, so that a recipe analysed once does not need to be analysed again. The recipe text itself is not stored — only the hash and the structured ingredient list the model produced from it.
Food records fetched from FoodData Central, cached so the site is not rate-limited. This is public nutrition data, not anything about you.
A count of which foods were used, and which phrases matched nothing. When an analysis finishes, the page sends one small message listing the identifiers of the foods it matched — flour-white, egg — and any phrases the food table could not match at all. That is the whole message: no recipe text, no title, no quantities, no serving count, no identifier of any kind, and the tables it lands in have no column to put one in.

It exists because the alternative is guessing. The foods that ship their nutrients inside the food index — the ones that make an ordinary recipe cost a single request — used to be picked by hand, and the database’s own hit counter can no longer do the job, because the static store answers most lookups without the database ever hearing about them. So the commonest foods had become the ones it never saw. The list of unmatched phrases is the other half: it is how a missing food gets added.

Photographs

Two features take a picture: reading a recipe off a page or a card, and scanning a nutrition label. Both work the same way and both are worth being explicit about, because an image is a different thing from a line of text.

The image is uploaded. It goes to this site’s server and from there to Anthropic’s Claude API to be read. Your browser shrinks it first — to cut the upload, not to hide anything. It is never stored: what comes back is text, and the image is discarded once it has been read.

A photographed recipe is treated exactly like pasted text from that point on: the transcribed ingredient list is stored against a hash of the image bytes, so photographing the same page twice does not cost a second reading. The recipe text is not stored, and neither is the picture.

A scanned nutrition label is different, and this is the important part. What the model reads off a packet — the product name, brand, serving size, every nutrient on the panel, the ingredient statement, the allergen line, any on-pack claims, the manufacturer and address if printed, and the barcode — is stored as a product record that anyone can read, at /api/products and on this site’s own pages.

That is deliberate. A nutrition label is public product information: it is printed on a box in a shop, it is the same for every packet, and once one person photographs a box of cereal everybody else gets it without paying for another reading. It is also the reason a re-scan is free.

It does mean two things you should know before you photograph something:

Do not photograph anything that is not a shop-bought packet. A handwritten note, a prescription label or a document is not a nutrition panel, and the model is told to refuse those — but the safe rule is not to send them.
Keep yourself out of the frame. Fill it with the panel. Nothing in the picture is stored, but nothing in the picture needs to be sent either.

If a product record needs correcting or removing, say so on the feedback page and it will be dealt with by a person.

None of it is tied to a cookie, a session, an account, or an IP-based identifier. There is nothing in the database that links a recipe to a person, and nothing that links two of these messages to each other.

What is never sent: your serving count, your edits, your swaps, your saved recipes, or the results. All of that is computed and kept in your browser.

If you would rather send nothing

The parser runs locally too. If /api/parse is unreachable, the site falls back to its built-in rule-based parser and its built-in food table, and works entirely offline after the page loads. Blocking /api/ in your browser gives you that mode deliberately — slightly less accurate matching, no data leaving your device.

What stays on your device

Saved recipes, in localStorage under ni.saved.v1. Never uploaded. Clearing site data deletes them.
The food lookup cache, under ni.foods.v2, so repeat lookups are instant.
Everything you edit — amounts, servings, ingredient swaps.

The analysis lives on its own page, so your recipe has to travel from the box you pasted it into to /analysis/. It travels in the URL fragment — the part after the # — and browsers never transmit a fragment to a server. So the recipe reaches the results page, survives a reload, and can be shared as a link, without any of it being sent here or recorded anywhere.

“Copy share link” builds the same kind of link from the recipe as you have edited it. It is visible only to whoever you send it to.

Importing from a web page

“Import a recipe from a web page” asks this site’s server to fetch that page and read the schema.org Recipe block it publishes — the same structured data that puts ingredients and cook times into a search result.

Only the ingredient list, the title and the serving count are read. The method is deliberately not fetched; there is a link back to the page for that.
Nothing is stored. The page is fetched, read and discarded within the request. The recipe then lives in your browser like any other, and travels to the results page in the URL fragment.
The site you are importing from sees a request from this server, not from you. Your IP address is not passed on. The request identifies itself as NutritionalValuesBot.
Addresses that are not on the public internet are refused, including after a redirect, so the fetcher cannot be pointed at anything private.

The suggestion form

The feedback form is the one place on this site where something you type is deliberately stored so that a person can read it later. It is worth being explicit about, because everything else on this page says the opposite.

Your message is stored and read. It is never published and never shown to another visitor.
Your email address is optional. That is the entire reason this is a form and not a mailto: link — an email client attaches your address whether you wanted it there or not. Leave it blank and nobody knows who sent it. If you do fill it in, it is used only to reply to you about your suggestion. It is not shared, not sold, and not added to any mailing list.
Your IP address is not stored. Something has to tell one sender from another to stop the form being flooded, so a salted digest of the address is kept instead — a fingerprint, from which the address cannot be recovered. The salt is a secret held on the server; where no such secret is configured, nothing is stored at all rather than something weaker.
Nothing about your recipes is attached. Recipes are not in the browser’s outbound path for this form at all.

Cookies

None. The site sets no cookies and loads no third-party scripts, fonts, pixels or embeds. The Content-Security-Policy blocks any attempt to add them.

Server logs

Cloudflare, which hosts the site, keeps standard request logs for operational and security purposes, covered by Cloudflare’s privacy policy. The /api/stats endpoint exposes aggregate counters only — how many lookups were served from cache, how fresh the food data is — and never any content.

Changes

If this ever changes — analytics, accounts, storing recipe text — it will be stated on this page before it ships, not after.

Analyse a recipe Rescale a recipe