Open Recipe Format: The New Standard for Recipe Portability
Most recipe formats were not designed for recipes. JSON is a general-purpose data format. CSV is a spreadsheet format. Markdown is a document format. They can all hold recipe data, but none of them were built with recipes in mind.
Open Recipe Format is different. It is a YAML-based format designed from the ground up to represent recipes -- with purpose-built fields for ingredients, steps, yields, oven temperatures, and source attribution. It is human-readable, machine-parseable, and built for portability.
MoveMyRecipes.com supports both importing and exporting Open Recipe Format files. Here is what you need to know about it and why it matters.
What Open Recipe Format Looks Like
ORF uses YAML, a plain-text format that reads almost like an outline. Here is a simplified example:
recipe_name: Classic Chocolate Chip Cookies
yields:
- servings: 24
prep_time: 15 mins
cook_time: 12 mins
oven_temp:
amount: 375
unit: F
ingredients:
- all-purpose flour:
amounts:
- amount: 2.25
unit: cup
- butter:
amounts:
- amount: 1
unit: cup
processing:
- softened
- chocolate chips:
amounts:
- amount: 2
unit: cup
steps:
- step: Preheat oven to 375 degrees F.
- step: Cream together butter and sugars until fluffy.
- step: Fold in chocolate chips and drop by spoonfuls onto baking sheet.
No special software required. You can read that. You can edit it in any text editor. And a computer can parse it into structured data because the fields are consistently named and formatted.
Why a Recipe-Specific Format Matters
Generic formats force you to make compromises when storing recipes.
CSV flattens everything into rows and columns. An ingredient like "2 cups all-purpose flour, sifted" becomes a single text string. There is no way for software to know that "2" is the amount, "cups" is the unit, "all-purpose flour" is the ingredient name, and "sifted" is the processing method -- without guessing.
JSON-LD (Schema.org) is excellent for web publishing, but its ingredient field is also just an array of text strings. The standard does not require ingredients to be broken into structured components. Most implementations store them as "2 cups all-purpose flour" rather than separating amount, unit, and name.
Markdown is pure text. It has no data structure at all. It is great for humans but tells software nothing about what is an ingredient versus what is an instruction.
Open Recipe Format solves this by giving ingredients their own structured schema. Each ingredient has a name, one or more amounts (with separate fields for quantity and unit), and optional processing instructions. This means software can reliably extract that you need "2 cups of flour" without having to parse a natural-language string.
This structured approach extends to other recipe-specific fields:
- Yields can specify multiple serving sizes (the same recipe scaled for 24 and 48 servings)
- Oven temperature has its own field with amount and unit (Fahrenheit or Celsius)
- Times are explicit fields: prep time, cook time, total time
- Source attribution includes separate fields for URL, book, and author
- Steps are a clean ordered list
Every field exists because recipes need it. Nothing is shoehorned into a generic structure.
How ORF Compares to Other Formats
| Feature | ORF (YAML) | JSON-LD | CSV | CookLang | Markdown |
|---|---|---|---|---|---|
| Human-readable | Yes | Somewhat | Yes (in spreadsheet) | Yes | Yes |
| Structured ingredients | Yes | No (text strings) | No | Yes (inline) | No |
| Multiple yields | Yes | No | No | No | No |
| Oven temperature field | Yes | No | No | No | No |
| Machine-parseable | Yes | Yes | Yes | Yes | No |
| Web standard | No | Yes (Google) | No | No | No |
| Plain text file | Yes | Yes | Yes | Yes | Yes |
ORF and CookLang are the only two formats that truly structure ingredient data. They take different approaches: CookLang embeds ingredients inline within instruction text using @ syntax, while ORF lists them separately with explicit amount/unit fields. Both are valid approaches for different use cases.
JSON-LD wins for web publishing and Google compatibility. CSV wins for spreadsheet workflows. But for portable, richly structured recipe data that a human can read and a computer can parse without ambiguity, ORF offers something the others do not.
How MoveMyRecipes Handles ORF
On our /convert page, you can upload .yaml or .yml files in Open Recipe Format. Our parser reads the ORF structure -- recipe_name, ingredients with their nested amounts and processing, steps, yields, timing fields, oven settings, source attribution, and notes -- and converts it to our internal Schema.org representation.
From there, you can export to any of our seven formats. This means ORF works as both an input and an output on MoveMyRecipes:
- Import: Upload an ORF YAML file and convert it to JSON, CSV, Markdown, CookLang, PDF, or HTML
- Export: Upload recipes in any supported format (Paprika, Cook'n, CopyMeThat, JSON-LD, CookLang, plain text, or images) and export them as ORF
This makes MoveMyRecipes a bridge between ORF and the rest of the recipe format ecosystem.
When ORF Makes Sense
ORF is a strong choice when:
You want structured data you can actually read. JSON-LD is technically readable, but the curly braces, quotation marks, and nested arrays make it dense. YAML's indentation-based structure is cleaner for human eyes.
You care about ingredient precision. If the difference between "2 cups flour" as a text string and "flour: 2 cups" as structured data matters to you -- for scaling, for unit conversion, for shopping list generation -- ORF delivers that structure natively.
You are building a personal recipe archive. A folder of .yaml files is a robust, long-term recipe collection. Each file is self-contained, readable without any special software, and easy to back up, version control, or share.
You want to support an emerging open standard. ORF represents the community's effort to create a purpose-built recipe interchange format. Using it and sharing feedback helps the format mature.
When ORF Might Not Be the Best Choice
For web publishing. If you are putting recipes on a website and want Google to display rich recipe cards in search results, JSON-LD with Schema.org is the established standard. Google does not read ORF.
For sharing with non-technical people. If you are sending a recipe to your aunt, a PDF or a simple text file is friendlier than a YAML document with nested data structures.
For spreadsheet workflows. If you want to sort, filter, and bulk-edit recipes in Excel or Google Sheets, CSV is the right tool.
The Case for Recipe-Specific Standards
The broader point behind ORF is this: recipes deserve formats designed for recipes. Generic formats work, but they force compromises. They store ingredients as unstructured text. They lack fields for oven temperature and yield scaling. They do not distinguish between prep time and cook time at a structural level.
When a format is designed for a specific kind of data, it can represent that data more faithfully. That is what ORF attempts, and it is why the format is worth paying attention to -- even if it is not yet the right choice for every situation.
You can try it yourself. Upload any recipe file to movemyrecipes.com/convert, choose Open Recipe Format as your export, and see what your recipes look like in a format built specifically for them.