Skip to the main story
RecipeJam

Recipes, collections & other kitchen matters

Ad-free · Yours, full stop. · ?.??

From the workshop

What We Take Out of Your Photographs

Every photograph of a plate of food carries a small amount of information about where you were standing. RecipeJam removes it twice, on purpose.

The RecipeJam workshop

A photograph taken on a phone is not only a photograph. Tucked into the file, in a section most people never see, is a note of the camera that took it, the moment it was taken and — very often — the precise spot on the earth where the photographer was standing. This is useful when you are looking for the holiday you cannot quite place. It is less useful attached to a picture of a lasagne taken in your own kitchen, on a recipe you have just published to a link you intend to share.

So RecipeJam takes it out. Not as a setting somebody has to find, and not as a promise in a privacy policy: the photograph is stripped before it is stored, and there is no version of it anywhere that still carries the original data.

Once in the browser, once on the server

The first removal happens on your own device, before anything is uploaded. The picture is decoded, turned the right way up, cropped if you asked, and then re-drawn onto a fresh canvas at the size RecipeJam actually needs. What comes out of that process is a new image built from pixels, with none of the original file’s hidden sections — which is why the location goes without having to be deleted.

The second removal happens on the server, and it exists because the browser only covers one door. A recipe imported from a web page never passes through it. Neither does a photograph posted by a script using the API, or one added by our own seeders. Those are stripped again on arrival. It is the same job done twice, and the duplication is the point: the day somebody adds a third way to get a photograph into RecipeJam, it is already covered.

A file the browser cannot read is refused rather than uploaded as it came. Sending the original would leak exactly the thing this exists to remove.

The refusal matters more than the removal

The interesting case is the one that fails. If a browser cannot decode the picture you chose — an unusual format, a corrupted file, a camera doing something inventive — the tempting behaviour is to send the original and let the server sort it out. RecipeJam refuses it instead and says so. An upload that quietly falls back to the untouched file is worse than an upload that does not happen, because you would have no way of knowing which one you got.

What this is not

This is not a privacy feature in the sense of a page of assurances. It is a small piece of plumbing, of the sort that costs nothing to get right at the start and is close to impossible to retrofit honestly, because by then the photographs are already stored. We are writing it down here mostly so that it is written down.