Why your calorie tracker does not count fiber — and how to fix it

You logged lentils, vegetables and wholegrain bread. The diary shows three grams of fiber.

What grates here is not the number, it is the uncertainty. Calories are there, protein is there, and fiber is not — so the app counted something and lost this particular field. Working out where it lost it is impossible from the diary itself: a gap and a measured zero look identical. And until you know which it is, every food decision is a guess. You can add more vegetables and get three grams again.

A zero in a diary is almost never measured. It appears in three places, and none of them is on your plate.

First: the label is not required to state it

#

In the US, a standard Nutrition Facts panel must carry dietary fiber.¹ In the European Union the mandatory declaration is built differently: energy, fat, saturates, carbohydrate, sugars, protein and salt. Fiber may be added — but is not required.²

We measured how visible this is in practice. In a sample of 565 real packaged products, calories, protein, fat and carbohydrate appear on roughly 95% of labels. Fiber appears on 72%.³

Every fourth product simply does not print the number. A scanner does not help here, but for a different reason than people assume: it does not read the label at all. It recognizes the code and pulls up an entry somebody created earlier. Sometimes that entry holds more than the package does — when it was built from laboratory or manufacturer data. More often it holds exactly what was printed, because it was filled in by a person holding the same package.

Second: a person filled in the entry

#

In databases where entries are added by users, an entry holds exactly the fields its author saw and chose to type in. MyFitnessPal marks team-reviewed entries with a check mark, and in the same place warns that a marked entry can still contain an error.⁴

Apps with a stricter approach have less of this problem, but it does not disappear. Cronometer recommends ordinary reference foods for detailed composition and says outright that if a nutrient is rarely populated in the source entries, the daily total can come out noticeably below actual intake.⁵ A branded entry holds what was on the label — and we already know what a label may not have.

USDA states the same rule for its branded-foods database: a missing value means the supplier did not provide it, not that the nutrient is absent. The same page describes the second trap — permitted rounding turns a small amount into a zero.⁶

Third: quick-add saves only what you typed

#

An entry that says “650 kcal” is useful if you are watching energy. It says nothing about fiber: the app has no idea whether those calories came from lentil soup or from a cream dessert.

The same holds for any input that returns only a total: a manual line with no nutrients, an unchecked estimate from a photo, an import from a service that does not pass every field. For a one-off dinner on a trip that is tolerable. For a breakfast that repeats five times a week it is a systematic understatement of the monthly total.

Settings will not fix it

#

If the field is absent from the entry you picked, nothing will create it — not a setting, not a recalculation, not a premium plan: the app has nowhere to get a number it was never given.

The number has to come from somewhere else. Usually that is a reference entry for the same food: reference sources (USDA, national databases, the data the detailed ledgers like Cronometer are built on) describe kinds of food rather than specific brands, and fiber is populated there. Less often it is a recipe built from ingredients, or a value typed in by hand from the label when the label prints it. What they have in common is the cost: manual work on every item that recurs and ought to be supplying fiber.

Start with the ones that are both frequent and substantial: legumes, whole grains, fruit, vegetables, nuts, seeds.

And one rule that saves the most time: do not fix a gap with arithmetic. If you do not know whether the carbohydrate line includes fiber, subtracting by hand counts it twice. In the US, total carbohydrate usually includes fiber; in several other systems it does not.

Why a reference table, a label and a user row disagree in the first place is covered separately in the food database lottery.

In Calk there are no empty fields

#

This is not a setting, and it is not the diligence of one particular entry — it is how the catalog is built. Nutrients live in the ingredient itself, not in a diary row, and they are populated for every ingredient. Lentils bring their fiber every time they land in a meal. There is no “the manufacturer did not provide the field”, no “the country does not require it on the label” and no “the user typed in only what they saw”, because none of those steps is in the chain.

One way to miss something remains: an ingredient you did not mark is not in the count. If you do not mark the seeds in a bowl, their fiber is not in the total, though the chickpea fiber is. The composition of the dish is visible on screen — the parts of the meal are listed, so a miss can be spotted and corrected.

Which is exactly why lentils have to stay lentils in the record instead of becoming an anonymous “400 kcal”. That is what a meal template is for: it keeps the component parts, and anything can be computed from them later.

The price of this decision is known and measured. Calk models ordinary kinds of food, not a specific brand. In a check across 243 packaged products, the median deviation in composition per 100 g from the label was 3.5% for calories and 14.4% for fiber.⁷ Fiber is one of the two weakest points of the model; only salt measures worse.

But look at what is being compared there: a generic food against a specific brand — the very thing Calk is not for. And even there it is fourteen percent, not a wipe to zero. The difference between “about 6 g” and “about 7 g” changes nothing about the decision you opened the diary for. The difference between 7 g and zero changes everything.

And then what all this was for becomes visible: the report names the foods that supplied your fiber all month, and the days when it had no sources at all. Fiber resting on a single bowl of oatmeal is not the same thing as the same average total coming from legumes, fruit, vegetables and grains, even though the number in the diary is identical.

How to tell it got better

#

Not by a nice number on one day, but by whether:

• recurring fiber sources are no longer logged as calories alone;
• the serving size matches your own estimate of what you ate;
• you no longer take an unfilled field for a measured zero;
• the report lets you name the specific foods that regularly supply fiber.

What to compare the corrected total against is explained in how Calk assesses fiber adequacy and carbohydrate quality.

Start with the one meal that repeats most often and ought to supply fiber: oatmeal, lentil soup, breakfast with fruit. Make sure the source stayed in the record as a separate ingredient. The next entries will show whether the low total was a property of your food or a property of your data.

Calk is available on iPhone, iPad, and Android.

Frequently asked questions

#

Sources and review date

#

Labelling rules and app features were checked on August 11, 2026. Entries and interface versions change; the principle that a gap is not a zero does not depend on them.