Cooking recipe description language
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.


Pesto specification draft

Pesto is a text-based human-editable and machine-transformable cooking recipe interchange format.


This specification is work-in-progress and thus neither stable, consistent or complete.

> module Codec.Pesto where

About this document

This section contains various information about this document. The second section motivates why inventing another file format is necessary, followed by the goals of Pesto. After a short Pesto primer intended for the casual user the language’s syntax__ and semantics__ are presented. The `linting section`__ limits the language to useful cooking recipes. Examples for user presentation of recipes and serialization follow.

Being a literate program this document is specification and reference implementation at the same time. The code is written in Haskell and uses the parsec parser combinator library, as well as HUnit for unit tests. Even without knowing Haskell’s syntax you should be able to understand this specification. There’s a description above every code snippet explaining what is going on.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.









The landscape of recipe interchange formats is quite fragmented. First of all there’s HTML microdata. Google rich snippets, which are equivalent to the microdata vocabulary, are widely used by commercial recipe sites. Although the main objective of microdata is to make content machine-readable most sites will probably use it, because it is considered a search-engine optimization (SEO). Additionally parsing HTML pulled from the web is a nightmare and thus not a real option for sharing recipes. h-recipe provides a second vocabulary that has not been adopted widely yet.

Most cooking-related software comes with its own recipe file format. Some of them, due to their age, can be imported by other programs.

Meal-Master is one of these widely supported formats. A huge trove of recipe files is available in this format. There does not seem to be any official documentation for the format, but inofficial ABNF grammar and format description exist. A Meal-Master recipe template might look like this:

---------- Recipe via Meal-Master (tm)

      Title: <Title>
 Categories: <Categories>
      Yield: <N servings>

    <N> <unit> <ingredient>

-------------------------------<Section name>-----------------------------
  <More ingredients>



Rezkonv aims to improve the Mealmaster format by lifting some of its character limits, adding new syntax and translating it to german. However the specification is available on request only.

A second format some programs can import is MasterCook’s MXP file format, as well as its XML-based successor MX2. And then there’s a whole bunch of more-or-less proprietary formats:

Living Cookbook
Uses a XML-based format called fdx version 1.1. There’s no specification to be found, but a few examples are available and those are dated 2006.
My CookBook
Uses the file extension .mcb. A specification is available.
Uses its own export format. However there is no documentation whatsoever.
The program’s export format suffers from the same problem. The only document available is the DTD.
Last updated in 2006 (version 1.0.4) for the german-language shareware program Kalorio has a custom and restrictive licence that requires attribution and forbids derivate works.
Cross-platform application, supports its own “emailed recipe format” and a simple YAML-based format.

Between 2002 and 2005 a bunch of XML-based exchange formats were created. They are not tied to a specific software, so none of them seems to be actively used nowadays:

Formerly known as DESSERT and released in 2002 (version 0.5). The license requires attribution and – at the same time – forbids using the name RecipeML for promotion without written permission.
Version 1.1 was released in 2002 as well, but the site is not online anymore. The DTD is licensed under the CC by-sa license.
Released in 2005 (version 0.5), aims to improve support for commercial uses (restaurant menus and cookbooks). The XSD’s license permits free use and redistribution, but the reference implementation has no licensing information.
RecipeBook XML
Released 2005 as well and shared unter the terms of CC by-sa is not available on the web any more.

Finally, a few non-XML or obscure exchange formats have been created in the past: YumML is an approach similar to those listed above, but based on YAML instead of XML. The specification has been removed from the web and is available through the Web Archive only.

Cordon Bleu (1999) encodes recipes as programs for a cooking machine and defines a Pascal-like language. Being so close to real programming languages Cordon Bleu is barely useable by anyone except programmers. Additionally the language is poorly-designed, since its syntax is inconsistent and the user is limited to a set of predefined functions.

Finally there is RxOL, created in 1985. It constructs a graph from recipes written down with a few operators and postfix notation. It does not separate ingredients and cooking instructions like every other syntax introduced before. Although Pesto is not a direct descendant of RxOL both share many ideas. has a similar list of recipe interchange formats.


First of all recipes are written by humans for humans. Thus a human-readable recipe interchange format is not enough. The recipes need to be human-editable without guidance like a GUI or assistant. That’s why, for instance, XML is not suitable and the interchange formats listed above have largely failed to gain traction. XML, even though simple itself, is still too complicated for the ordinary user. Instead a format needs to be as simple as possible, with as little markup as possible. A human editor must be able to remember the entire syntax. This works best if the file contents “make sense”. A good example for this is Markdown.

We also have to acknowledge that machines play an important role in our daily life. They can help us, the users, accomplish our goals if they are able to understand the recipes as well. Thus they too need to be able to read and write recipes. Again, designing a machine-readable format is not enough. Recipes must be machine-transformable. A computer program should be able to create a new recipe from two existing ones, look up the ingredients and tell us how many joules one piece of that cake will have. And so on.

That being said, Pesto does not aim to carry additional information about ingredients or recipes itself. Nutrition data for each ingredient should be maintained in a separate database. Due to its minimal syntax Pesto is also not suitable for extensive guides on cooking or the usual chitchat found in cooking books.

Introduction by example

So let’s start by introducing Pesto by example. This text does not belong
to the recipe and is ignored by any software. The following line starts the


+1 l water

+100 g penne
&10 min

>1 serving pasta
(language: en)

And that’s how you make pasta: Boil one liter of water in a pot with a little bit of salt. Then add 100 g penne, cook them for ten minutes and you get one serving pasta. That’s all.

There’s more syntax available to express alternatives (either penne or tagliatelle), ranges (1–2 l water or approximately 1 liter water) and metadata. But now you can have a first peek at my own recipe collection.

Using this project

This project uses cabal. It provides the Codec.Pesto library that implements the Pesto language as described in the previous sections. It also comes with three binaries.