Website Errors

How to Fix 409 Conflict Error

409 ConflictPlain English: your request clashes with the current state of the thing you are changing — usually you are editing an outdated copy, or the name you picked already exists.
Quick answer: The server is refusing your request because it no longer fits the current state of the resource. Reload the page or file to get the latest version, check whether your change already went through, then re-apply it on the fresh copy. If you are creating something, rename it to something unique. The full steps are below.

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

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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 ETag or Last-Modified headers 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

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.