Free Recipe & Nutrition APIs in 2026 — Compared
Five providers. Two of them answer completely different questions, and picking the wrong one is the usual failure.
For recipes with zero setup: TheMealDB (test key 1, no signup). For barcoded products and label nutrition: Open Food Facts (no key). For computed nutrition on real recipes: Spoonacular (150 points/day). For drinks: TheCocktailDB. For ingredient-text parsing: Edamam.
Free recipe API and free nutrition API land people on the same page, but they describe two unrelated datasets. A recipe API tells you what to cook and how. A nutrition API tells you what is in a thing you are about to eat. Most of the wasted afternoons in this category come from wiring up the wrong one and discovering the mismatch three days later. Everything below sits in the food API category, checked hourly — our methodology explains what those checks measure.
Comparison
| API | Data | Free tier | Auth | Rate limit | Best for |
|---|---|---|---|---|---|
| TheMealDB | Recipes | Test key 1 free; supporter key for production | None (key 1 in path) | No published counter — fair use | Prototypes and tutorials |
| TheCocktailDB | Drinks | Test key 1 free; supporter key for production | None (key 1 in path) | No published counter — fair use | Cocktail and drinks apps |
| Open Food Facts | Packaged products | Free, no key, full dataset downloadable | None, but an identifying User-Agent is mandatory | No hard counter — product lookups are cheap, search is not | Barcode and packaged-food data |
| Spoonacular | Recipes + nutrition | 150 points/day (about 50 searches); paid from 29 USD/mo | Free key (email signup) | 150 points/day, weighted per endpoint | Computed nutrition for recipes |
| Edamam | Recipes + nutrition | Free developer tier; commercial from 69 USD/mo | Free key (App ID + App Key) | Low per-minute and per-month ceilings | Ingredient-text nutrition analysis |
Recipes and packaged products are not the same dataset
Internalize this before you write a line of code. Open Food Facts is keyed on barcodes: scan a jar of pasta sauce and you get its ingredients, allergens, nutrition per 100g, Nutri-Score and NOVA class. It knows nothing about cooking. TheMealDB and Spoonacular are keyed on dishes: ingredients, measures, instructions, and in Spoonacular's case a computed nutrition panel. They know nothing about the brand of sauce in your cupboard. Diet trackers need both, so build two ingestion routes with two caches from the start — identifiers, units and confidence levels all differ.
The providers
1. TheMealDB
Free tier: Test key 1 in the URL path, no signup. Supporter key via Patreon for production
Coverage: Roughly 300 meals with ingredients, measures, step-by-step instructions, cuisine filters and good photography
Auth: None (key 1 in path)
Rate limit: No published counter — fair use
Best for: Tutorials, hackathons, recipe-browser prototypes
The fastest recipe API to get running, which is why it appears in every tutorial. Ingredients arrive as twenty numbered fields — strIngredient1 through strIngredient20 with matching strMeasure fields — not an array, so write the normalization loop once at the fetch boundary. Search is exact-ish on meal names with no typo tolerance, so chiken returns nothing: add a fuzzy layer, or pull by first letter with search.php?f=c and filter client-side. The test key is documented as development and education only, and gates latest.php plus multi-ingredient filtering. The catalog skews British and international home cooking, and the dietary category fields are not comprehensively populated.
2. TheCocktailDB
Free tier: Same model — test key 1 free for development, supporter key for production
Coverage: 600+ cocktails with ingredients, measures, glass types, alcoholic flags and images
Auth: None (key 1 in path)
Rate limit: No published counter — fair use
Best for: Bartending apps, party planners, drink pairings alongside a meal API
Same maintainer, same access model, same JSON conventions — if you have an adapter for TheMealDB, this is a half-hour port. The useful endpoint is the ingredient filter behind every what-is-in-my-cabinet app, but on the free key filter.php?i=Gin matches one ingredient only; multi-ingredient intersection is a supporter feature, so fetch per-ingredient lists and intersect client-side. Measures are free-text strings — 1 1/2 oz, 2 shots, Juice of 1/2 — so unit conversion needs a parser. And random.php returns alcoholic drinks by default; check strAlcoholic for a family-friendly mode.
3. Open Food Facts
Free tier: Free and unmetered. Nonprofit, ODbL licence, full dataset downloadable, commercial use allowed if you share back derived databases
Coverage: Three million-plus packaged products by barcode: ingredients, allergens, nutrition per 100g, Nutri-Score, NOVA class, product photos
Auth: None, but an identifying User-Agent is mandatory
Rate limit: No hard counter — product lookups are cheap, search is not
Best for: Barcode scanners, diet trackers, allergen checkers, sustainability tooling
The only free, open, globally scoped barcode-to-food-data source that exists — every commercial alternative meters you per call. Three things bite. The identifying User-Agent is mandatory (app name, version, contact URL or email), and default client agents are blocked at the CDN, so you get a generic error page rather than an explanation. Every field is optional in practice: nutriments can be empty, energy may exist in kJ but not kcal, ingredient text may be French but not English. Null-check everything — a tracker that treats missing sugars as zero is worse than one that says unknown. And for a barcode you already hold, hit the v2 product endpoint directly; search is slow under load, and paging it for bulk work is what gets you blocked. Take the published dump instead.
4. Spoonacular
Free tier: Free key on email signup, 150 points/day — roughly 50 recipe searches. Paid from about 29 USD/month
Coverage: Large recipe index with computed nutrition, recipe parsing from a URL, ingredient substitution, meal planning, wine pairing
Auth: Free key (email signup)
Rate limit: 150 points/day, weighted per endpoint
Best for: Nutrition for real recipes, meal planners, recipe-URL importers
The one free tier here that answers the question people actually arrive with: how many calories are in this recipe. It computes nutrition for full recipes, parses a recipe out of a URL you hand it, suggests substitutions and does wine pairing. The catch is the points budget: requests are weighted, so a complex search with nutrition attached costs several times a plain lookup and 150 points evaporates faster than the number suggests. Treat it as an evaluation budget, not a serving budget — cache on the exact query, resolve recipes to IDs once, and never let a search box call it on every keystroke.
5. Edamam
Free tier: Free developer tier per API with low ceilings and non-commercial terms. Commercial plans from about 69 USD/month
Coverage: Recipe search over a publisher index, a food and grocery database, and natural-language nutrition analysis of ingredient lines
Auth: Free key (App ID + App Key)
Rate limit: Low per-minute and per-month ceilings
Best for: Ingredient-text parsing, recipe search over publisher content
The other serious paid option, worth evaluating alongside Spoonacular rather than instead of it. Edamam splits its offering into three separately-keyed products, which trips people up: a key issued for Recipe Search does not work against Nutrition Analysis. That analysis endpoint is the differentiator — hand it a plain-text line such as two cups of cooked brown rice and it returns structured macros, exactly the parsing problem you would otherwise solve yourself. The developer tier is explicitly non-commercial and the step up is a real one at 69 USD/month.
Where the free tier genuinely is not enough
No free API gives you reliable nutrition for an arbitrary cooked recipe. Open Food Facts covers barcoded packaged goods and stops there; computing macros for chicken curry with rice means paying for Spoonacular or Edamam, or building it yourself on USDA FoodData Central — free and excellent as a reference database, but it hands you raw ingredient entries and leaves the parsing, unit conversion, cooked-versus-raw yield factors and portion maths to you. That is a multi-week project, not an afternoon.
Two patterns that work
Barcode scan with graceful unknowns. Call the Open Food Facts v2 product endpoint with a proper User-Agent and render what came back with every field guarded. Cache the payload keyed on the barcode — packaged data changes on the timescale of packaging redesigns, so a long TTL is safe and keeps the app usable offline. Show unknown rather than zero.
Recipe browser on a points budget. Serve browsing and filtering from TheMealDB, which has no meaningful ceiling, and reserve Spoonacular's 150 daily points strictly for the nutrition panel on a recipe someone actually opened. Persist every Spoonacular response keyed on recipe ID — you buy that record once, permanently, not once per view.
Frequently Asked Questions
What is the best free recipe API?
For learning and prototypes, TheMealDB — the test key needs no signup and the data is real cooking content with photography. For computed nutrition or recipe parsing from a URL, Spoonacular is the only free tier that does it, at 150 points a day. TheMealDB will not run out on you; Spoonacular will, so cache it from day one.
Is there a free API for nutrition data?
Yes, with a caveat about which kind. Open Food Facts is free, needs no key, and covers three million-plus barcoded packaged products with nutrition per 100g, Nutri-Score and NOVA classification. Spoonacular and Edamam compute nutrition for prepared recipes on limited free tiers. No free API reliably returns nutrition for an arbitrary home-cooked dish.
What is the difference between Open Food Facts and TheMealDB?
They answer different questions and are not substitutes. Open Food Facts maps a barcode to a packaged product — what is in this jar, what allergens it carries, what its Nutri-Score is. TheMealDB and Spoonacular return recipes: what to cook, what to buy, what the steps are. Choosing wrong is the most common mistake in this category.
Is there a free recipe API with no API key?
Open Food Facts needs no key at all, though it does require an identifying User-Agent naming your application and a contact address. TheMealDB and TheCocktailDB use the shared test key 1 directly in the URL path, which is effectively keyless for development. Spoonacular and Edamam both require a free key from an email signup.
What happened to the Yummly API?
It was retired and never replaced, which is why so many older tutorials point at dead endpoints. Nutritionix moved to a paid-first model around the same period. That churn is most of the reason this category looks thinner than it did five years ago — what remains genuinely free is TheMealDB for recipes and Open Food Facts for packaged goods.
Can I use these recipe APIs commercially?
Open Food Facts data is ODbL-licensed and commercial use is allowed provided you share back any derived database. TheMealDB and TheCocktailDB ask you to move to a supporter key for production, a small one-time Patreon tier. Spoonacular allows commercial use on paid plans. Edamam's free developer tier is explicitly non-commercial.
Related on FreeAPI.watch
- Food API live status — hourly checks for every API on this page
- Free APIs with no API key — broader list of no-signup endpoints
- Free book APIs — the same treatment for book data
- How we measure free-tier quality — the score behind our rankings
Last reviewed: August 2026. Verify terms against each provider's docs before deploying.