Open Food Facts without the 9MB JSON blob

Open Food Facts is a genuinely great public resource — 2M+ products, crowd-sourced, no API key, licensed CC-BY. The problem is what comes back. One product can be a 9MB nested JSON document: nutriments split across per-100g / per-serving / per-100ml, labels in five languages, photos you didn't ask for, and a categories array that doubles as a taxonomy lesson. If you want "name, brand, sugar per 100g, Nutri-Score," you are parsing a small phone book.

Open Food Facts Extractor flattens that into one row per product. Search, grab a specific barcode, or pull by brand — typed records out:

// search by term
{ "mode": "search", "searchTerms": "nutella", "maxResults": 50, "sortBy": "popularity" }

// a specific product by barcode
{ "mode": "product", "codes": ["6111246721261"] }

// or everything under a brand
{ "mode": "by_brand", "brands": "bel" }

Each record carries the fields people actually query: product_name, brands, categories, quantity, countries, ingredients_text, allergens, labels, plus the nutrition block (energy_100g_kcal, fat_100g, sugars_100g, proteins_100g, salt_100g) and the scoring trio — nutriscore_grade, ecoscore_grade, nova_groups. All strings, all flat, ready for a spreadsheet or a vector store.

Where it earns its keep

Nutrition and food apps are the obvious one — build a local product cache without re-parsing OFF on every lookup. But the scoring fields make it useful further out: a NOVA-distribution sweep of a supermarket's private-label range, or a Nutri-Score leaderboard per category, is a one-run dataset, not a weekend of JSON wrangling.

One gotcha worth knowing

Open Food Facts rate-limits datacenter IPs with the occasional 503. The actor retries with backoff (four attempts, increasing delay), so a normal run recovers on its own — but if you are hammering it at high concurrency you will feel the throttle. Keep batches reasonable and let the retries do their job.