# Why Obsidian sync conflicts happen, and why merging afterwards is too late

> Obsidian Sync merges markdown with diff-match-patch once both copies are finished, which is why text comes back doubled. What removes the conflict instead.

Source: https://baalda.com/blog/obsidian-sync-conflicts
Site: Baalda, https://baalda.com
Published: 2026-10-10

**Short answer.** A conflict happens when the same file changes on two devices before they sync. Obsidian merges markdown with Google's diff-match-patch, which applies patches best-effort, so its own docs warn the result may contain duplicate text. Merging two finished files is a guess. Merging edits as they are typed is not.

There are two ways to get one note onto two machines. Replicate the file and reconcile the copies afterwards, which is what every sync service does, or merge the edits as they are made, which is what a collaborative editor does. Obsidian Sync is the first kind. A conflict is not a failure of the first kind. A conflict is what the first kind is, showing up on a day when the timing was bad. Baalda, the app this site is for, is the second kind, and most of this post is about what that actually changes and the two things it does not.

## Why does Obsidian Sync create a conflict at all?

Obsidian's own definition is the short version: "A conflict happens when you change the same file on two or more devices before they sync." The help page adds that conflicts happen more often when you work offline, because there are more changes and longer gaps between syncs.

What matters is what Sync has to work with when it notices. It has two finished files. It does not have the keystrokes, the order they arrived in, or who made them. It has the version from before, the version your laptop ended up with, and the version your phone ended up with, and it has to produce one file out of that. Everything else about conflicts follows from working with three end states instead of a stream of edits.

Obsidian then does three different things depending on what the file is:

- **Markdown** is merged, using Google's diff-match-patch algorithm.
- **Everything else, including canvases**, uses "a 'last modified wins' approach", so the most recently modified version replaces the earlier one.
- **Settings JSON**, such as plugin settings, is merged by applying "keys from the local JSON on top of the remote JSON".

That is not unusual. Every tool that replicates files is doing some version of it:

| Where the note is replicated | What happens when it changed in two places |
|---|---|
| Obsidian Sync, markdown | Merged with diff-match-patch, or written to a separate conflict file if you changed the setting |
| Obsidian Sync, canvases and attachments | Last modified wins. The earlier version is replaced |
| Dropbox | No merge. Dropbox "won't try and merge the changes" and keeps both, one renamed with the editor's username and "conflicted copy" |
| Syncthing | Both kept, the older renamed `<filename>.sync-conflict-<date>-<time>-<modifiedBy>.<ext>` |
| Git, through a plugin | The pull stops and leaves conflict markers in the file for you |

Obsidian's merge is the most ambitious row in that table. It is also the only one that can hand you back a file that looks fine and is wrong.

## Why does the merge come back with the text doubled?

Because diff-match-patch is designed to apply a patch even when it no longer fits. Google's own README describes the three parts of the library, and the patch component is "Apply a list of patches onto plain text. Use best-effort to apply patch even when the underlying text doesn't match." The match component is "Given a search string, find its best fuzzy match in a block of plain text."

Read those two together and the doubled paragraph stops being mysterious. You rewrote a section on the laptop. You rewrote the same section on the phone. One side's patch arrives carrying context that is no longer anywhere in the file, the fuzzy matcher finds the nearest thing it can, and best-effort means it lands rather than failing. So the rewrite goes in next to the rewrite, and you get both.

Obsidian says so, plainly, in the description of the default setting. Automatic merge "saves all edits, but it may sometimes create duplicate text or formatting problems that you will need to fix manually."

This is not a bug in diff-match-patch. The library is doing exactly what it advertises. The information you would need to merge the two versions correctly, which edit came first and which character belongs to which session, was discarded the moment the two devices went their own way with nothing but files between them. The merge is a reconstruction of intent from two end states, and there is no algorithm that does that reliably, because the intent is not in the bytes.

## How do you fix the conflict in front of you right now?

Three things, in order.

**Change the policy.** Starting in Obsidian 1.9.7 you can pick, under Settings, Sync, Conflict resolution. "Automatically merge" is the default. "Create conflict file" writes a separate file instead, so you review both versions and merge them yourself. If you would rather see the collision than discover it three weeks later in a doubled paragraph, take the second one.

There is a catch worth knowing before you rely on it. Obsidian states that "Conflict resolution settings are device-specific. You must configure your preferred option on each of your devices." Setting it on your laptop does nothing for your phone.

**Recover the clean version.** Select the note, Open version history, pick the version from before the merge, Restore. On mobile, long-press the file for the same menu. Retention depends on the plan: Sync Standard keeps one month of note history, Sync Plus keeps twelve, and older versions of attachments are kept for two weeks either way. Deleted files have their own list, under Settings, Core plugins, Sync, Deleted files, View.

**Stop running two sync systems on one vault.** Obsidian's switching guide is direct about this: "We do not recommend using Obsidian Sync alongside cloud storage services (e.g. iCloud, Dropbox, OneDrive, Google Drive) as this can cause conflicts." Obsidian will try to detect it and show a message at the top of Sync's settings, but it is worth checking by hand, because a vault that sits inside an iCloud or Dropbox folder has two independent replicators writing the same files and neither knows about the other.

None of that stops the next one. It changes what the next one looks like and gives you a way back.

## What would have to change for the conflict not to exist?

The merge has to happen while both people are typing, not after both have stopped.

That is the whole difference, and it is a different place in the stack rather than a better algorithm. Baalda keeps your notes as plain markdown files on your own disk, the same as Obsidian does, and puts a CRDT between the open copies instead of a reconciler behind them. From the app's README: "the `.md` file on disk is the durable source of truth, and a live CRDT keeps every open copy in sync." It runs on Yjs with a Hocuspocus server.

Concretely, the loop is two-way and operation-shaped:

- When you, or an AI, or `git`, changes a file, a watcher turns that change into CRDT operations.
- When a teammate edits the shared note, those operations flow back and are written to your file.

And the line that decides whether you ever see a conflict file: "Every change funnels through the same CRDT as operations, never whole-file overwrites."

An operation carries where it belongs. Two of them arriving at once do not need a tiebreak, because they are not two versions of a document, they are two insertions into one. There is never a moment at which two complete copies of a note exist and something has to pick. Nothing is reconstructing intent, because the intent was never thrown away.

The same path covers the AI, which is the part that bites teams later. An agent rewriting a paragraph through Baalda's MCP endpoint is another source of operations, not a process that opens the file, rewrites it whole, and leaves your editor's copy to be reconciled with it afterwards. Running an agent over a vault that syncs by file replication means adding a third writer that works offline by definition.

Dropbox, of all places, states the conclusion in its own help page. Its advice for avoiding a conflicted copy is that if you are "unable to collaborate in real-time", the next best thing is to move the file out of the Dropbox folder while you work on it. That is file locking described as a workaround, and it is what you are left with when merging after the fact is the only merge you have.

## What happens once a second person shares the vault?

It compounds, in three ways that each make the others worse.

Obsidian's collaboration page is explicit: "Obsidian does not yet support collaborative live editing on the same file. You will not see the other user's cursor, and their edits will only appear once the changes are synced." So in a shared vault, every simultaneous edit is a conflict waiting to resolve, and you have no signal at all that it is happening. You find out afterwards, in the file.

The device-specific setting is worse with people than with devices. Your teammate may have "create conflict file" on their laptop while you are on the default. The same collision then resolves differently depending on whose machine noticed it first, and neither of you configured the other's.

And there is nowhere to put a boundary that would reduce the surface. A shared vault is shared whole: at most 20 collaborators, every one of them needing an active Sync subscription, and "All collaborators receive the same permissions as the vault owner, with one exception: only the vault owner can invite collaborators." Everyone can edit everything, so everyone is a potential second writer on every note. We go through the rest of that trade in [can Obsidian be a team knowledge base](/blog/obsidian-team-knowledge-base) and, for the access half, [Obsidian per-file permissions](/blog/obsidian-per-file-permissions).

The editing half of the same problem, live cursors and what it takes to have them on markdown files, is [multiplayer Obsidian](/blog/obsidian-multiplayer-realtime-collaboration).

## Where merging as you type still leaves you a decision

Three places, and they are not small.

**It removes the file conflict, not the editorial one.** Two people who rewrite the same sentence at the same time get both rewrites, interleaved, in one document. Nobody lost anything and nothing was guessed at, but the sentence is now wrong and a person has to fix it. The gain is that this happens in front of both of you, while you are both there, instead of surfacing in a file called `note (conflicted copy)` on a Tuesday. It is a better failure, not an absent one.

**It merges inside a note, not across notes.** Two people who each create a note at the same path while disconnected have made two notes. No merge algorithm can tell you they meant the same one, and nothing in a CRDT changes that.

**It needs a server.** Obsidian Sync needs one too, but Syncthing and iCloud do not, and that matters if your reason for leaving Sync was to run no service at all. If you are one person on two devices, editing one at a time, Obsidian Sync's merge is genuinely fine and the conflicts you hit are the handful of times you forgot to let the phone finish syncing. Switching your whole setup to fix those is a larger answer than the question. The point at which this stops being true is the point at which a second person starts typing. The rest of that comparison is in [Baalda vs Obsidian](/compare/obsidian).

## FAQ

### How do I stop Obsidian Sync from merging automatically?

Settings, Sync, Conflict resolution, and pick "Create conflict file" instead of the default "Automatically merge". The option arrived in Obsidian 1.9.7. One thing to know before relying on it: Obsidian states that "Conflict resolution settings are device-specific. You must configure your preferred option on each of your devices." Setting it on your laptop leaves your phone on the default, and the same collision then resolves differently depending on which machine noticed first.

### Can I get back the version from before the conflict?

Usually, through version history. Select the note, Open version history, pick the version from before the merge and Restore. On mobile, long-press the file for the same menu. How far back you can go depends on the plan: Sync Standard keeps one month of note history and Sync Plus keeps twelve, while older versions of attachments are kept for two weeks on both. Deleted files have a separate list under Settings, Core plugins, Sync, Deleted files, View.

### Does using iCloud or Dropbox instead of Obsidian Sync avoid conflicts?

No, it changes the shape of them. Dropbox's help says it "won't try and merge the changes" and keeps both versions, one renamed with the editor's username and "conflicted copy". Syncthing renames the older copy to `<filename>.sync-conflict-<date>-<time>-<modifiedBy>.<ext>`. Neither doubles your text, because neither attempts a merge at all, so you get two files to reconcile by hand. Running one of them alongside Obsidian Sync on the same vault is worse than either: Obsidian's own guidance is that "We do not recommend using Obsidian Sync alongside cloud storage services (e.g. iCloud, Dropbox, OneDrive, Google Drive) as this can cause conflicts."

### Do conflicts get worse when a second person shares the vault?

Yes, and you lose the warning signs. Obsidian's collaboration page states that "Obsidian does not yet support collaborative live editing on the same file. You will not see the other user's cursor, and their edits will only appear once the changes are synced." A shared vault is also shared whole, with at most 20 collaborators who all hold the vault owner's permissions, so everyone can edit everything and every note has more than one possible writer.

### Does a CRDT mean nothing ever has to be resolved?

No. It removes the file-level conflict, not the editorial one. Two people who rewrite the same sentence at once end up with both rewrites in one document, nothing lost and nothing guessed at, and somebody still has to read the result and choose. It also merges inside a note rather than across notes: two people who separately create a note at the same path while disconnected have made two notes, and no algorithm can tell you they meant one.