How to Fix 409 Conflict Error
What 409 Conflict means
The 409 status is the server saying "this request does not fit anymore." Unlike a 404, where the thing you want is missing, or a 500, where the server itself broke, a 409 means the server understood your request perfectly well and deliberately refused it — because carrying it out would overwrite, duplicate, or contradict the current state of the resource. The most common trigger is editing a stale copy: you opened a document, a wiki page, or a settings screen, someone else changed it while you were working, and now your save is based on a version that no longer exists.
The second classic trigger is a duplicate. Try to create a file, folder, username, or database record whose name or key is already taken, and a well-built server answers 409 instead of silently creating a second copy. That is why the error feels so stubborn: hammering the retry button with the exact same request will keep failing, because nothing about the request changed. The fix is always to bring your side up to date first — load the current version, see what actually happened, and then act on that fresh picture.
Common causes
- Editing a stale copy: you loaded a page, document, or record, and someone else — or another one of your own devices — changed it before you saved. Your edit is based on an outdated version, so the server rejects it rather than overwriting the newer work.
- A duplicate name or key: the file, folder, username, or record you are trying to create already exists under that exact name. Uploading "report.pdf" twice or registering a taken username are the everyday versions of this clash.
- Two people editing at once: collaborative tools, shared drives, and admin panels all hit this when two users change the same item simultaneously. The first save wins; the second save meets a changed resource and gets a 409.
- Sync and version mismatches: cloud storage apps and version-controlled files compare version numbers or checksums before accepting a change. If your local copy is behind the server copy, the sync is refused until you pull the latest version down.
- A double-submitted request: a form submitted twice, a payment retried after a slow response, or an upload restarted mid-flight can create a second request that collides with the first one, which already succeeded. The server sees the duplicate and answers 409.
How to fix 409 Conflict — step by step
The whole fix takes about ten minutes: reload, check what actually happened, and re-apply your change on the current version.
- Reload the page and look at the current version. A 409 usually means you are editing an old copy: someone else changed the same page, file, or record while you were working on it. Reload the page or reopen the file and read the current version before touching anything. You may find your change is already there, or that the other person's edit explains exactly why yours was refused.
- Check whether your change already went through. Do not submit the same change twice just because the first attempt returned 409. Search for the item, open the list, or check the history: the first request may have partially succeeded, and a duplicate attempt is exactly what the server is guarding against. If the change is already in place, you are done — the conflict was the server telling you the work was finished.
- Re-apply your change on the fresh copy. Once you have the current version, make your edit again on top of it rather than resubmitting the old form or old file. If the page offers a merge view, a compare screen, or a prompt to keep your version, use it and review every conflicting line before saving. Save once, then confirm the result looks right instead of assuming it did.
- Rename the item if a duplicate name is the clash. When the 409 comes from creating or uploading something, the usual culprit is a name that already exists — a file, a folder, a username, or a record with the same key. Give the item a different, more specific name and try again. If the system warns that the name is taken, believe it: the existing item is the conflict, not a bug.
- Clear stale cache and retry from a fresh session. A browser or app holding a cached, outdated copy can keep resubmitting the old version and tripping the same conflict. In Chrome, open Settings, then Privacy and security, then Delete browsing data, and clear cached images and files. Reload the page, sign in again if needed, and perform the action once on the freshly loaded version.
- If you run the site, make conflicts recoverable. When your own users keep hitting 409, the fix is on the server side. Return the current version of the resource in the conflict response so clients can merge instead of guessing. Support conditional requests with
ETagorLast-Modifiedheaders so stale edits are caught early, and use unique idempotency keys on creates so a retried request is recognized as a duplicate instead of a second conflicting create.
Did this fix it? Quick checklist
- The page or file was reloaded and the current version reviewed before any new save was attempted
- It was checked whether the change had already gone through, so the same request was not submitted twice
- The edit was re-applied on the fresh copy, or the item was renamed when a duplicate name was the clash
- Stale cache was cleared and the action retried once from a fresh session; site owners return the current version in conflict responses
One more spot to check if it still fails: try the same action in a private or incognito window, signed in fresh. If it works there but never in your normal browser, an extension or a cached session is resubmitting old data — disable extensions one by one until the conflict stops. And if the 409 appears on a shared drive or sync folder, check the sync client's conflicted-copy folder first: your file may already exist there under a "conflicted copy" name, and renaming or merging that copy is the real fix.
Frequently asked questions
What does 409 Conflict mean?
It means your request conflicts with the current state of the resource on the server. The classic case is editing a stale copy — someone changed the same page, file, or record after you loaded it — but it also fires when you try to create something whose name or key already exists. The server refuses the request rather than silently overwriting or duplicating data.
Is a 409 error my fault or the website's?
Usually neither — it is a normal safety mechanism doing its job. If you edited an old tab, uploaded a file with a name that already exists, or double-submitted a form, the conflict came from your side and a reload plus a fresh attempt fixes it. If it fires on a first attempt with a unique name, the site may be generating duplicate keys or mishandling version checks, and the site owner needs to look at it.
How is 409 different from 412 Precondition Failed?
They are cousins. A 409 says your request clashes with the resource's current state in general — a stale edit, a duplicate name, a locked record. A 412 is narrower: it fires only when a specific precondition you sent, like an If-Match header with an ETag, evaluates to false. Think of 409 as the server saying "this does not fit anymore" and 412 as it saying "the exact condition you asked for is not true."
I run the website — how do I stop 409s for my users?
Make conflicts visible and recoverable: include the current version of the resource in the 409 response body, support ETag and Last-Modified conditional requests so clients can detect stale copies before submitting, and accept idempotency keys on create endpoints so a retried request is deduplicated instead of conflicting. Also surface a clear in-app message — "this was changed by someone else, here is the latest version" — instead of a bare error page.