How we build MyFoodAnalysis

Our source values come from FoodData Central, the U.S. Department of Agriculture's food composition database. We use its full download, release 2026-04-30. Our scheduled check looks for newer downloads every Monday; importing, testing and publishing an update are separate manual steps. This site is a snapshot, not a live copy of USDA's database.

USDA's foods come from four sources, and each food page tells you which, with a link to the same food on USDA's own site:

• Foundation: analytical data on sampled foods, with information about their variability.
• SR Legacy: USDA's classic nutrition tables, kept up until 2018.
• Survey: nutrient and portion data compiled for foods reported in USDA's national eating survey.
• Branded: manufacturer label information supplied by food industry data providers.

These are different kinds of evidence: inclusion in FoodData Central does not mean USDA independently measured a product. See USDA's data type documentation.

• The current generic records in our selected download. We use the Foundation, SR Legacy and Survey tables and exclude 74 older records present elsewhere in this release. For those older IDs, the API redirects to a current record with the same USDA name and data type when one exists; otherwise it returns Gone. This matching rule does not establish that two analyses are nutritionally identical.
• The latest record per product barcode in our download. We select about 442,000 products from about 2 million branded records. USDA's online branded data can be newer than this download; a record is not a guarantee of the label currently on a shelf.
• We leave out Experimental Foods and records of individual lab samples. We do not include every record in FoodData Central.

• Reported values and estimates are distinct. The source table at the bottom of each food page keeps USDA's reported values, per 100 g or, for products labeled by volume, per 100 ml. The panels scale values to your chosen serving. Values that use our assumptions say Estimated, and the page explains how they were obtained. A dash means the value was not reported and has not been estimated.
• Some nutrients are recorded more than once. USDA sometimes stores the same nutrient in two or three ways. When it does, we always use the same one, in this order:
  • Calories: USDA's standard calorie figure. Many of USDA's newest lab-tested foods don't have one; for those we use the calories USDA calculated using food-specific Atwater factors, then USDA's general Atwater figure. If all of those are absent, we estimate using 4 calories per gram of protein and carbohydrate and 9 per gram of fat, plus 7 per gram of alcohol when reported. Unreported alcohol is assumed zero. We require all three macros and reject inputs whose combined mass, including reported alcohol, exceeds 102 g per 100-unit basis. This is an approximation; fiber, sugar alcohols and food-specific energy factors can make the actual value differ.
  • Carbohydrates: USDA's usual figure, which is what remains of 100 g after water, protein, fat and minerals are measured; otherwise the carbohydrates added up from the measured sugars, starch and fiber.
  • Sugars: USDA's standard total sugars; otherwise the second total USDA keeps for some foods.
  • Folate: the figure used on nutrition labels (dietary folate equivalents, which counts added folic acid as better absorbed); otherwise total folate.

  The full list, with USDA's nutrient numbers, is in mfadata/nutrients.py.

• Net carbs are carbohydrates minus fiber (never less than zero). USDA doesn't publish them; we work them out. When fiber is unreported, we show an Estimated upper bound, assuming zero fiber, and state that assumption. This does not mean the food has no fiber.
• Negative values are floored at zero in the panels. Because USDA works out carbohydrates as what is left after everything else is measured, small measuring errors can leave a tiny negative number: for 10 raw meats and fish it is as low as −0.7 g. We show 0 g on the label and in rankings; the full table keeps USDA's exact figure.
• % Daily Value uses the FDA's Daily Values for adults and children 4 and older, the same ones printed on U.S. food labels.
• Packaged products come from their labels. USDA standardizes them per 100 g or 100 ml, matching the supplied unit. For volume-based products, our gram-based panels use the approximation 1 ml ≈ 1 g and label the resulting values Estimated. That is our density assumption, not a density supplied by USDA. It is less reliable for oils, syrups and concentrates. Scaling back to the label serving approximately recovers its reported amounts; the source table stays per 100 ml. Label rounding is another source of uncertainty. USDA explains this in its branded data documentation.
• Estimates travel with the number. Food pages, search, rankings and Food Finder mark estimated values. The API includes their methods, and recipe totals identify estimated inputs and nutrients missing from any ingredient. A partial total is not a complete estimate.

USDA names foods like a library catalog: “Cheese, cheddar”, “Fish, salmon, Atlantic, wild, cooked, dry heat”. We name them the way people say them: “Cheddar cheese”, “Wild Atlantic salmon, cooked”. USDA's own name is always shown under ours.

• An AI model wrote the new names for the foods from USDA's labs, tables and survey (about 13,400 of them). It is Qwen 3.8 (27B), running on our own server through Catalyst. Its instructions: keep every detail that changes the nutrition (raw or cooked and how, skin, fat trim, salt), and never add a brand.
• Code checks every AI name before it is used. The name must keep a word for the food itself, and it must keep the qualifiers in USDA's description that change what the food is: raw or cooked, reconstituted or not, with or without salt, processed, powdered, dried, frozen, canned, concentrate, fat level, diet, sweetened or not, skin, and every percentage (such as “85% lean”), compared as numbers so “15%” never passes for “5%”. The cooking method must survive (roasted stays roasted) and a name may not add one USDA does not allow: “cooked, dry heat” may become grilled or baked, never boiled. Negations are checked as phrases, so “not reconstituted” is never read as “reconstituted”. A name that fails is not used: the food keeps USDA's description (about 620 foods in this release). The checks cover that fixed list of qualifiers, not every possible detail, so USDA's description is always shown on the food page. The names in use are in mfadata/names.json, free for anyone to reuse.
• Packaged products keep their label names; names written in all capitals are shown in normal case, with the brand in front.

Every page leads with one serving. Branded foods use the label serving. For generic foods we pick from the portions USDA weighed for that food, the way each kind of food is eaten, following the FDA's reference amounts for label serving sizes: a slice or an ounce of cheese, a tablespoon of butter or honey, two tablespoons of peanut butter, a slice of bread, a large egg, an ounce of nuts or chips, a 12 fl oz can of beer; otherwise a natural unit (“1 banana”) or a common household measure, never a sliver such as 1 fl oz.

Where USDA lists no such portion, we state a weight instead: 3 oz (85 g) for meat, poultry and fish, 1 oz for cheese, nuts and chips. A weight needs no estimate (an ounce is 28.35 g of any food), while a cup or a tablespoon weighs differently for every food, so we use those only when USDA weighed them. A drink without a cup is shown per 8 fl oz, eight times USDA's own weight for 1 fl oz of that drink.

Generic-food servings stay under 350 g (a can of beer, 355 g, is the exception). Pages fall back to an available portion or 100 g if no serving is selected. This is a display choice, not a recommended amount to eat. The interactive panels follow your selection; the source table and comparison panels retain the basis stated in their headings.

• By default, the “foods high in…” lists and Food Finder use a subset of generic records that we classify as everyday foods. Packaged products are excluded from this default view.
• Our category and description rules exclude dried spices and herbs, baby foods and formula, protein powders and isolates, and some regional specialties. These rules are a browsing filter, not a judgment about a food's value. Excluded foods still have pages.
• A ranking shows a USDA description once, choosing the record with the most nutrient values when USDA lists the same description in two sources. Food Finder shows every record, so similar foods from different sources can both appear.
• “Per 100 calories” leaves out foods with almost no calories (under 10 per 100 g), where the comparison stops meaning anything.

Every USDA record (every FDC id) has its own page. A record points search engines to another as its main page only when both conditions hold: USDA describes the two in exactly the same words (for packaged products, the same brand too), and they agree on every nutrient either one reports: the same nutrients present, and each value within 2% or a small amount for its unit (0.1 g, 1 mg, 1 µg, 2 kcal). For packaged products that means two barcodes share a page only when their labels are equivalent value for value, such as one product in two package sizes. The main page is the record with the most nutrient values, or for packaged products the most recent label. Our generated names play no part in this.

Records that share a description but differ in any value keep their own pages; in this release about 33,500 do, and about 15,900 point at a main page. Site search shows main pages only. Two records with similar names are not the same food unless they meet the rule above; the USDA description on each page tells you which record you are looking at.

We tell search engines about our pages in stages: first the everyday foods and the products of about fifty national brands. Products whose labels list fewer than six nutrients are not offered at all. Every page is still on the site either way.

We run automated tests as a separate validation step. The database build does not run them automatically. The checks cover:

• Food IDs and original descriptions against the selected USDA release, using the inclusion rules above.
• Raw nutrient values for a fixed random sample of 300 foods against the CSV, within numerical tolerance. This is a sample check, not a check of every nutrient in the database.
• A saved USDA API snapshot collected on September 24, 2026 covers 20 selected foods. Seventeen current records receive nutrient comparisons; three superseded records receive redirect/removal checks. Survey comparisons allow for rounding. These API tests and their snapshot are in the private service repository, not the public data repository.
• Branded-record selection and available serving sizes against the selected download.
• Energy consistency and relationships such as saturated fat within total fat. These tests allow specified exception rates and rounding tolerances. Passing does not mean every record is consistent: some source records still have saturated fat above total fat or sugars above carbohydrate. An estimate label also does not establish that an estimate is accurate for a particular product.

The public CSV and consistency tests are in tests/; tests requiring source files skip if those inputs are missing. Check the test summary for skipped checks. If a number looks wrong, compare it with USDA using the FDC id at the bottom of the food page, and tell us at info@objectgraph.com.

How we prepare the data is open source at github.com/objectgraph/myfoodanalysis-data. Download the same USDA release, run our build, using the corresponding code version and included name file to reproduce the processing. The public tests cover the CSV import and consistency rules; the website and API service are not open source. Comparing with USDA checks our handling of its data, not the accuracy of a manufacturer's label or the nutrient content of the particular food you eat.

MyFoodAnalysis is made by ObjectGraph LLC (about us). It is information, not medical advice.