Recipe File Formats Compared: Cooklang vs Markdown vs JSON-LD vs MealMaster
There's no single standard for storing recipes digitally. Different formats emerged from different eras and different needs — BBS systems, XML web services, SEO, and plain text editing. Each makes trade-offs between human readability, machine parseability, and ecosystem support.
Here's the same simple recipe — a tomato pasta — written in six different formats, with honest pros and cons for each.
Cooklang
Cooklang annotates natural recipe text with markers for ingredients (@), cookware (#), and timers (~). The recipe reads naturally while being machine-parseable.
Pros: Reads like a normal recipe. Ingredients, cookware, and timers are embedded in the instructions, so you never lose context. Plain text files work with Git, any text editor, and any sync service. Growing ecosystem of tools (CLI, mobile apps, editor plugins).
Cons: Not a web standard — doesn't give you SEO rich snippets. Fewer tools than formats backed by Google or the food blogging industry.
Best for: Personal recipe collections, developers, anyone who wants recipes as portable text files.
Plain Markdown
The most common "format" for digital recipes — just write it in Markdown with no formal structure.
Pros: Everyone knows Markdown. Renders nicely everywhere. No special tools needed.
Cons: Not machine-parseable — a computer can't reliably extract "400g canned tomatoes" from a Markdown list because there's no standard structure. No automated shopping lists, no scaling, no nutritional calculation. Every Markdown recipe template is slightly different.
Best for: Notes, quick drafts, blogs that don't need structured recipe data.
Schema.org JSON-LD
The format that powers recipe rich snippets in Google search results. Embedded as a <script> tag in HTML pages.
Pros: Google, Bing, Pinterest, and other platforms understand it. Gets you rich search results with images, ratings, and cook times. The dominant format for recipe SEO.
Cons: Not human-readable or human-writable. Nobody writes recipes in JSON — it's generated by CMS plugins. Ingredients are still free-text strings (no structured quantities). Web-only — useless for offline recipe management.
Best for: Food blogs and recipe websites that need search engine visibility.
MealMaster
Created in the late 1990s for Episoft Systems' MealMaster software. Designed for BBS compatibility with strict column-based formatting.
Pros: Huge legacy archive of recipes from the BBS era — thousands of recipes exist in this format. Simple and readable.
Cons: Strict column-width requirements make it fragile and hard to parse reliably. Limited metadata support. No active development. The ecosystem is decades old.
Best for: Archival purposes. If you have a MealMaster collection, tools exist to convert them to modern formats.
RecipeML (XML)
An XML-based format created in 2000, originally called DESSERT. The first attempt at a structured, platform-independent recipe format.
Pros: Properly structured — ingredients have separate quantity, unit, and item fields. Enables unit conversion, scaling, and nutritional calculation. XML validation catches errors.
Cons: Extremely verbose. Nobody wants to write recipes in XML. The format never gained mainstream adoption and is essentially dead.
Best for: Historical interest. If you need structured ingredient data, Cooklang achieves the same result with less syntax.
Open Recipe Format (YAML)
A YAML-based format designed for developer-friendly recipe storage with support for professional kitchen metadata (HACCP instructions, processing keywords).
Pros: Clean and readable. YAML converts easily to JSON. Structured ingredient data with separate fields. Version control friendly.
Cons: Ingredients and instructions are separate — you lose the connection between "add garlic" in the steps and the garlic entry in the ingredients list. Small ecosystem with limited tooling.
Best for: Developers building recipe applications who want structured data without XML verbosity.
Summary
| Format | Human Readable | Machine Parseable | Ecosystem | Active Development |
|---|---|---|---|---|
| Cooklang | Excellent | Yes | Growing | Yes |
| Markdown | Excellent | No | Huge (generic) | N/A |
| JSON-LD | Poor | Yes | Massive (SEO) | Yes |
| MealMaster | Good | Fragile | Legacy | No |
| RecipeML | Poor | Yes | Dead | No |
| Open Recipe Format | Good | Yes | Small | Minimal |
The fundamental tension is between human readability and machine parseability. Markdown is the easiest to write but computers can't reliably extract structured data from it. JSON-LD is perfectly machine-readable but nobody writes it by hand.
Cooklang sits in the middle — you write natural recipe text, and the @, #, ~ annotations make it machine-parseable without sacrificing readability. That's why we built it.
Try Cooklang → | Language specification →
-Alex