How do apps detect duplicate recipes, and why does it matter?

What is a duplicate recipe, and why do they pile up?

Reposting. A recipe that works spreads, so within a fortnight of something going viral 6 accounts have posted their own version, and you saved 3 of them because each looked new in the moment you saw it.

There are 3 further sources worth knowing. The same recipe reaching you on 2 platforms, once on TikTok and once on Pinterest. Importing the same web page twice, months apart. And a screenshot of a recipe you also saved as a link.

None of these feel like duplication at the time, which is why it accumulates without anybody noticing until search stops being useful. It is a specific case of the pattern in why saved recipes get lost.

Why does title matching not work?

Because the same dish has no consistent name. One recipe circulates as baked feta pasta, viral tomato pasta, that TikTok pasta, 4-ingredient pasta and a caption consisting of 3 emojis.

Comparing those titles finds nothing in common. Worse, title matching produces false positives in the other direction: chicken curry and chicken curry might be 2 genuinely different recipes from different cuisines that you want to keep separately.

How does ingredient comparison work?

By treating a recipe as a set of ingredients and asking how much 2 sets overlap. If 2 recipes share 9 of 10 ingredients in similar proportions, they are almost certainly the same dish regardless of what they are called.

Three refinements make it usable rather than annoying. Staples are weighted down, because salt, oil and pepper appear in everything and tell you nothing. Quantities are compared in proportion rather than absolutely, so a version for 2 matches a version for 4. And unit differences are normalised, so cups and grams do not read as a mismatch.

• High overlap on distinctive ingredients is the strong signal: feta, gochujang, tahini, preserved lemon.
• High overlap on staples alone is a weak signal, since half your library shares those.
• Similar method length and cooking time is a supporting signal, not a decisive one.
• This only works if the recipes were imported as structured ingredients in the first place.

That last point is the dependency worth repeating: a library of bookmarks cannot be deduplicated at all, because there are no ingredients to compare. Detection is downstream of import quality, as what is a recipe importer sets out.

Should an app merge automatically?

No, and this is where a well-intentioned feature can lose your data. Two versions of a dish frequently disagree on quantities, and silently merging them means picking one set of numbers without telling you.

Sometimes the disagreement is the important part. One version uses 200 g of flour and one uses 250 g, and if the 250 g version is the one you have cooked successfully twice, an automatic merge that keeps the other has quietly broken a recipe you rely on.

Flagging is the correct behaviour: show the 2 side by side, show where they differ, and let you choose. That takes 10 seconds and preserves the version you trust.

What does a duplicate cost you?

Small amounts of friction in places that compound, which is why duplicates get tolerated far longer than they should be.

Search is the obvious one. Three results for one dish means comparing before cooking, and after that happens a few times people stop searching and go back to the 5 recipes they remember. A library that is not trusted is functionally the same as no library.

• Planning gets worse, since the same dish can be scheduled twice in a week under 2 names.
• Grocery lists inflate, because 2 copies of a recipe contribute 2 sets of ingredients.
• Notes fragment: the version you annotated is not the version you opened.
• Dietary checks have to be repeated on every copy rather than once.

The planning consequence is the one that surprises people, and it is a real failure in automatic planning. If a planner draws from a library containing 3 copies of one dish, that dish is 3 times more likely to be chosen, so the generated week quietly skews towards whatever you happened to save repeatedly. AI planning from your library covers what the planner does with a library, and a deduplicated one gives visibly better weeks, because each dish gets counted once rather than according to how often you happened to save it.

Which copy should you keep?

Four criteria, in order. They resolve nearly every case without much thought.

1. 1The one you have cooked. If either version has notes or a rating from you, keep that one regardless of anything else.
2. 2The one with explicit quantities. A version saying 2 tbsp beats one saying a drizzle.
3. 3The one whose source is still live. Useful if you might want to rewatch the technique.
4. 4The one with the better title. Easiest to fix, so it decides only genuine ties.

Before deleting the loser, move any notes across. Notes are the most valuable thing in a recipe library and the easiest to lose in a tidy-up, which is part of why back up your recipes is worth reading before a big clear-out. For general library upkeep, organize digital recipes covers the rest.

A reasonable maintenance habit is to deduplicate at import rather than in periodic clear-outs. Checking whether something is already in the library takes 2 seconds at the moment of saving, when you still remember what you have, and it prevents the job ever becoming an afternoon. Clear-outs are the expensive way to solve this, because by then you have forgotten which version you cooked and which one you only meant to.

On apps, ReciBites vs ReciMe covers another social-first library and ReciBites vs Paprika covers a manual, library-first approach.

Ingredient set overlap

The proportion of ingredients 2 recipes share, weighted so distinctive ingredients count for more than staples.

False positive

Two recipes flagged as duplicates that are genuinely different, such as 2 unrelated curries with the same name.

Normalisation

Converting units and proportions to a common basis so a recipe for 2 can be compared with the same recipe for 4.