The foods in MacroFactor’s database come from two sources: highly vetted research databases, and verified user-submitted entries.
This differs considerably from apps that rely on unverified, user-submitted foods to build their massive databases. When a user creates a new food and enters erroneous nutrition information, that erroneous food entry will be added to the database. So, while a user-built database does contain a lot of items, finding the entry with correct nutrition information might require a considerable amount of hunting. These databases can be a pain to sift through, and users are more likely to log foods with incorrect nutrition information – making their data messy and unreliable.
MacroFactor takes a different approach. When it comes to our food search database, we value both quantity and quality, but with an emphasis on quality.
With verified food search databases (like the ones MacroFactor uses), user submissions are all checked for accuracy by other humans before the foods are added to the public database. As a result, the number of duplicate foods and the number of foods with erroneous nutrition information is dramatically reduced.
Even with these quality standards in place, MacroFactor still has a very large food search database containing more than 1,360,000 verified items with robust macro- and micronutrient reporting.
However, our high standards mean that there can be some limitations.
MacroFactor’s coverage is very robust for common food items (staples like meat, dairy, rice, fruit, and vegetables), as these have well-established nutritional values that don’t change much between localities. Branded or rare ingredients may not be as well covered.
Coverage is also generally quite good for processed/manufactured food products that come in standard packaging with nutrition information. Sometimes, entries may be slightly out of date – for example, a food manufacturer may change their formulation for a food product, but the latest nutrition information hasn’t made it to the database yet.
Conversely, it’s possible to experience the same effect in reverse with some foods with a long shelf life; if you have a long-lasting food item on your shelves, then the manufacturer updates the formulation and that makes it into the database before you end up consuming it, then you might find that your version of the food ends up disagreeing slightly with the latest version in the database and on store shelves.
Coverage is not as strong for restaurant food items, as restaurants are less likely to report their nutrition information. Major chains that publish their nutrition information may be included, but this won’t always be the case.
Barcode coverage is excellent in the United States, Canada, the UK, Australia, Ireland, New Zealand, Japan, France, and Spain. The barcode support is quickly improving in Germany, as well. Countries outside of those may see fewer localized options, but barcode support is growing over time, and users can still log from the huge library of common foods, add custom foods and recipes for local foods, and use the Label Scanner functionality to quickly scan and add any food with a nutrition label.
In the case that a certain food isn’t covered in the database or you find an incorrect entry, the best approach is to create a custom food entry by using the “copy to custom” option. You can even associate barcodes with the custom foods you create, so that you can quickly log foods using barcode scanning, even for foods that aren't in our databases.
This is a little bit of extra work in the short term, but if you consume a lot of the same food items regularly, you’ll quickly reach the point at which you’ve created enough custom food entries to cover all your major foods, and it won’t take any additional time going forward.