Where do the ten entries come from?
From the users, one at a time. A crowd-sourced food database is the tracker's catalogue of foods typed in by the people who use it: a yoghurt added in 2013 from a pack that has since changed, the same yoghurt added by someone else with the per-serving figures instead of per 100 g, a third time with a typo, a fourth as a homemade recipe under the brand's name. Nothing in the diary says which one is right, because the person who could tell is not there, and the search box returns them all.
The people who live with it describe it the same way across a decade. One MyFitnessPal community member wrote in June 2013 that "the same food item can be listed a hundred times with different calorie counts", and a reply the same day gave the coping rule: when unsure, pick the higher count. In January 2022 an r/Myfitnesspal user wrote: "Sometimes there are 10 or more entries that all show vastly different calories. I end up searching other databases to figure out which entry is closest, then adjusting the serving size until it shows what I think is the correct calories." Both threads were read on 4 September 2026.
It is not a small complaint. In a 2026 study in Nutrition Journal by Li and colleagues, dissatisfaction across 455 245 US app reviews was driven first by the food database, ahead of fees. And the study of food journalers that named the barriers, Cordeiro and colleagues at CHI 2015, had its participants name "multiple postings with all different information" and "too many choices" among them, and say that manual entry pushed them toward barcoded processed food. The reason is plain enough: a barcode is one entry and a plate of dal is ten.
Why does it matter which entry you pick?
Because the choice is the record, and the number of rows says nothing on its own. Some of them are real distinctions, a different brand, a different preparation, raw against cooked, and picking the right one of those is ordinary work. The trouble is the rows that differ for no reason you can see. Pick the per-serving row when you meant per 100 g and the yoghurt is wrong by the ratio between the two; pick the 2013 row and the pack has changed; pick the higher one to be safe and the day drifts up by a habit rather than by a meal. None of those is a rounding error, and none of them is visible afterwards: the row says "Greek yoghurt", not "the third of ten entries, chosen by a user in a hurry".
| What you see | What is behind it | What it costs |
|---|---|---|
| Ten rows for one yoghurt | Ten users' readings of packs, old and new, per serving and per 100 g, plus a few guesses | A choice, every time, with no way to tell which is right |
| A "verified" tick on some rows | A row the app has marked as checked, by a process its own pages describe and this article does not | A better guess at the right row, still no source on the figure in your diary |
| A barcode that finds one row | A packaged product matched to its label | Works well for packaged food, and pushes the diary toward it |
| A homemade dish under a brand's name | A user's recipe, saved as if it were a product | A figure for someone else's kitchen, in yours |
| The row you picked last time | Your own past choice, right or wrong | The same error, repeated with confidence |
Bottom line: a database that lets anyone add a row makes everyone choose one, and the choice never shows in the diary.
The honest fix is not a cleaner database, though a curated one helps and some trackers keep one. It is a record where each item says where its numbers came from, so that a wrong row is a row you can find, rather than a choice you made in a search box six weeks ago.
What does IZeat do instead of a food database?
IZeat is the calorie tracker inside ChatGPT, Claude or any other assistant. Tell the assistant you already use what you ate instead of searching for foods and entering them one by one. There is no built-in food database and no search box, so there is nothing to pick from. You describe the food, a packaged one by its label, a plain one by its weight, a dish by its size and what went in, and the assistant is asked to value it and to name the source on each item: label, reference, user or estimate.
That moves the choice from a list to a sentence, which is where you can see it. "A 150 g pot of plain Greek yoghurt, the label says 97 kcal per 100 g" is one row from the label, scaled to 150 g, with the values read back to you before they are stored. "180 g of cooked chicken breast" is asked to be valued as one reference row for the grams you said. "A bowl of my dal, about 200 g" is asked to be recorded as an estimate that states what it assumed, marked as one, and the first row to question if the day looks wrong. None of them was chosen from ten.
Two rules keep it that way. Nothing you record becomes anyone else's entry: your rows are yours, in your record, never merged into a shared catalogue for the next customer to pick from. And IZeat looks nothing up itself today: a reference value is the assistant's reading of a standard composition table, recorded as reference. If IZeat one day adds open reference data, such as the packaged-product database Open Food Facts, that data will live in its own table, attributed to its source, and never be blended with customers' figures into a database of IZeat's own. The four sources article says how each kind of figure reads.
What you give up without a database: no database means no barcode scanner and no autocomplete, and a food you cannot describe is a food the assistant has to ask about. What you get for that is a record with no tenth entry in it, and a source on every row.
Frequently asked questions
Short answers to the questions people type, each one sourced above.
Why does MyFitnessPal show ten entries for the same food?
Partly because brands, preparations and raw or cooked states really are different foods, and partly because the database is crowd-sourced: users add them per serving or per 100 g, from packs old and new, and the duplicates are not removed. One community member wrote in 2013 that the same item "can be listed a hundred times with different calorie counts"; another in 2022 described searching other databases to guess which of ten entries was closest. Both threads were read on 4 September 2026.
Which entry should I pick when there are many?
There is no reliable rule, which is the problem; the one a community member offered in 2013 was to take the higher count when unsure, and a rule like that drifts the day upward by habit. A row the app marks as checked is the better bet where one exists, and a barcode usually finds the right packaged product. For a plain food, a reference table for the grams you weighed beats any user row; through IZeat that is what the assistant is asked to use.
Where do IZeat's figures come from, if there is no database?
From one of four sources, named on each row. You describe the food to the assistant you already use, and the figure is recorded from a label you showed, a reference table for a plain food you weighed, a figure you gave, or an estimate that says so, with the source on the row. If IZeat adds open reference data, it will stay apart and attributed; nothing you record becomes another customer's entry.
Is a crowd-sourced database less accurate than a reference table?
It is less checkable. A reference table gives one figure per plain food, measured across samples by an agency; a crowd-sourced database gives many figures per food, each someone's reading or guess, and the diary does not say which you took. A study of 455 245 US app reviews found the database the first driver of dissatisfaction, ahead of fees. The wrong row is not the worst part; the invisible choice is.
What about barcodes?
A barcode finds one packaged product and its label, which is why it works well and why manual-entry trackers push people toward barcoded food. IZeat has no scanner today: a packaged food is recorded from its label, photographed or read out, with the values read back to you before they are stored. Open Food Facts, the open database of packaged products, is the kind of reference data IZeat could add later; if it does, it stays apart and attributed.
Can my own entries be wrong in IZeat too?
Yes, and the record is built so you can find them. A label can be misread past the readback, a weight can be said cooked when it was raw, an estimate can assume a bowl bigger than yours. Each row carries its source, so a week later you know which rows to question first; one sentence corrects a row, and the earlier state stays in the meal's history. What cannot happen is picking the wrong row from a list.
Will my entries end up in someone else's diary?
No. Your rows are yours, in your record, and never become a row another customer picks from a list. IZeat holds no shared food catalogue today. If it ever adds open reference data such as Open Food Facts, that data is published under a licence requiring attribution and share-alike, so it would stay in its own table, attributed, and never be blended with customers' figures into a catalogue of IZeat's own.