You order pad thai from a Thai restaurant on DoorDash. You open your calorie tracking app, search "pad thai," find a result that looks close, log 650 calories, and move on. You have done everything the app is designed for you to do. You have also almost certainly logged the wrong number — possibly by 200–400 calories — and the error is not your fault. It is structural to how these databases are built.

The core problem with calorie counting delivery food in apps like MyFitnessPal, Lose It, and Cronometer is not user error. It is a database architecture problem: these apps were built around USDA generic food entries and chain restaurant nutritional disclosures, neither of which maps accurately onto the food that comes out of the kitchen at your actual delivery restaurant. Understanding why the gap exists is the first step toward working around it.

How Calorie Tracking App Databases Are Built

Calorie tracking apps draw from several types of data sources, and each source has its own accuracy characteristics:

Data Source What It Contains Accuracy for Delivery Food
USDA FoodData Central Lab-tested generic ingredients and standardized dishes Accurate for ingredients; poor for restaurant dishes
Chain restaurant submissions Nutritional data submitted directly by chains (required for 20+ locations) Accurate for that chain; ±20% FDA tolerance
User-submitted entries Entries created by app users from labels, guesses, or other sources Highly variable; no verification; frequently wrong
Barcode-linked packaged food Manufacturer data from packaged food barcodes Accurate for the specific product scanned

The last category — packaged food barcodes — is where calorie apps are genuinely reliable. The first two categories are reasonable for chain restaurants and cooking from scratch. The user-submitted entries, which make up the majority of restaurant-specific entries in most apps, are where the delivery food problem lives.

📊 The MyFitnessPal database reality: MyFitnessPal's database contains over 14 million food entries. The vast majority of restaurant-specific entries were submitted by users who estimated nutrition from what was available (menus, delivery app listings, other apps) rather than from verified nutritional testing. A single restaurant dish like "chicken tikka masala" may have dozens of entries with calorie counts ranging from 400 to 1,100 — all appearing equally valid in the search results.

The Three Layers of Error for Delivery Food Specifically

Layer 1: Generic USDA Data Doesn't Match Restaurant Portions

The USDA defines standard serving sizes for nutritional reporting. A USDA entry for "pad thai, restaurant prepared" uses a defined portion weight — typically 200–250g — and measures nutrients for that weight. The portion of pad thai that arrives from your delivery order weighs 450–650g in most cases. When you search the app, log one serving, and the app pulls the USDA entry, you are recording nutrition for roughly half of what you ate.

As we document in our analysis of how delivery portion sizes distort your calorie count, delivery portions routinely run 2–3x USDA standard serving sizes for grain-based dishes. The user who dutifully logs "1 serving of pad thai" after a delivery order has logged roughly 650 calories when the actual meal delivered was 1,100–1,350 calories. They did nothing wrong by app standards. The app standard does not match delivery reality.

Layer 2: Restaurant Preparation Adds Invisible Calories

USDA generic entries are calculated from ingredient-level data using standardized preparation methods. Restaurant preparation is not standardized in the same way. The oil quantity used in a wok preparation, the butter finish on a grilled protein, the sugar content in a house sauce — none of these are reflected in a USDA generic entry, and restaurants are not required to disclose them unless they operate 20 or more locations.

The practical effect: a USDA "stir-fried chicken with vegetables" entry might record 380 calories for 200g. A restaurant stir-fry of the same weight, prepared with restaurant-quantity oil in a wok, may contain 520–600 calories. The gap is entirely invisible to the person logging from the USDA entry. The restaurant did not use unusual ingredients — they just cooked the way restaurants cook, with more fat than home cooks typically use.

Layer 3: User-Submitted Entries Are Systematically Unreliable

The entries most people use when logging delivery food are user-submitted restaurant-specific entries: "Panda Express Orange Chicken," "Chipotle Chicken Bowl," "XYZ Thai Pad See Ew." These entries exist because users created them — often from memory, from partial menu information, or by copying numbers from other apps without verification.

A 2019 analysis of popular calorie tracking app databases found that user-submitted entries for restaurant foods had an average error rate of 31% compared to verified nutritional analysis, with individual entries ranging from accurate to more than 100% off. The problem is not that most entries are wrong — it is that you cannot tell from the app which entries are accurate and which are not. The five-star popular entry and the completely fabricated entry look identical in the search results.

The Database Matching Problem

Even when a calorie tracking app has access to accurate nutritional data, matching your specific delivery item to the right database entry is a genuinely hard problem. Consider the search for "chicken burrito":

If you ordered from Chipotle, there is a reasonable chance you find the right entry. If you ordered from a local Mexican delivery restaurant, there is no entry that accurately represents your specific burrito, and you are choosing from a range of approximations with no guidance on which is closest.

Where Sodium Tracking Fails Hardest

Calorie miscounts get most of the attention, but the sodium tracking failure for delivery food may be more consequential for health outcomes. USDA generic entries for restaurant dishes typically show sodium levels based on standardized recipes. Restaurant sodium levels are consistently higher because restaurants salt aggressively at multiple stages of preparation.

A user logging "chicken fried rice" from a USDA generic entry might see 720mg of sodium recorded. The actual delivery order, prepared with restaurant-quantity soy sauce and seasonings, likely contains 1,400–2,100mg of sodium. The person tracking their sodium believes they are at 720mg when they are at twice that level. For someone managing blood pressure or kidney health from app data, this is not a minor tracking error — it is the difference between staying under the USDA Adequate Intake of 1,500mg/day and blowing past it on a single meal.

⚠️ The sodium gap in delivery tracking: Research consistently finds that self-reported sodium intake from calorie tracking apps underestimates actual intake by 30–50% for people who eat restaurant food regularly. The primary driver is not user carelessness — it is the systematic difference between USDA-standard sodium values and restaurant-prepared sodium content. The same meal logged identically by two people — one eating home-cooked, one eating delivery — will have wildly different actual sodium content despite identical app records.

The Specific Problems with Major Tracking Apps

MyFitnessPal

MyFitnessPal's large database is its main advantage and its main liability. The 14+ million food entries include an enormous number of user-submitted restaurant items with no quality verification. The app does display "verified" badges for some entries, but verification typically means the data matches a label the user photographed — not that the data was independently tested. For delivery food from independent restaurants, the verified badge rarely appears because no verified source exists.

Lose It

Lose It uses a combination of USDA data and restaurant-submitted entries, with fewer user-submitted entries than MyFitnessPal. This makes it slightly more reliable for chain restaurant items but does not solve the independent restaurant problem. The app has integrated directly with some delivery platforms to pull in menu item data, which is an improvement — but delivery app nutritional data is itself often unverified, as discussed in our piece on fast food calorie label accuracy.

Cronometer

Cronometer is the most conservative of the major apps in accepting user-submitted data, relying primarily on verified sources including USDA FoodData Central and branded food databases. This makes it more accurate for packaged foods and ingredients but leaves the same gap for delivery food: independent restaurant dishes are not in the verified database, and the closest USDA generic entry may be significantly off from the actual delivery meal.

What Actually Works for Tracking Delivery Nutrition

Precise calorie tracking from delivery orders using current consumer apps is not achievable with reliable accuracy. There are, however, approaches that produce better information than the default:

Scenario Logged Calories (App) Estimated Actual Gap
Delivery pad thai (full order) 650 kcal 1,100–1,350 kcal +450–700 kcal
Chicken burrito bowl (local restaurant) 680 kcal 950–1,150 kcal +270–470 kcal
Grilled salmon (delivery, verified chain) 520 kcal 560–640 kcal +40–120 kcal
Pizza (2 slices, chain) 560 kcal 580–660 kcal +20–100 kcal
Sashimi platter (Japanese delivery) 380 kcal 360–440 kcal ±60 kcal

The pattern is consistent: dishes where the gap between standardized USDA data and restaurant preparation is largest — sauce-heavy, oil-heavy, large-portion preparations — produce the worst tracking accuracy. Dishes with minimal preparation and straightforward composition (sashimi, grilled proteins without sauce) track more reliably.

A Better Framework for Delivery Nutrition

The calorie tracking problem for delivery food is not going away. The data infrastructure for precise restaurant nutrition tracking does not exist at scale, and building it would require disclosure requirements that current regulations do not mandate.

What is achievable is a better question: instead of asking "how many calories did I eat from delivery today," ask "is my delivery eating pattern meeting my nutritional needs." That question is answerable with USDA DRI benchmarks applied to your actual order history — and the answer tells you more about what to change than a calorie count that may be 30% wrong.

For the full picture of delivery nutrition gaps, see what your delivery orders say about your nutrition and our side-by-side comparison of restaurant versus home cooking nutrition.

Stop Guessing. Start Scoring.

BiteBetter analyzes your actual delivery receipts against USDA DRI benchmarks — so you get nutrient adequacy data, not app-estimated calories that miss by 30%.

Try the free demo → See pricing