An HTTP 409 Conflict error means your request conflicts with the current state of the resource on the server. The server cannot process your request because it would create a logical contradiction with existing data. This typically happens when two users try to edit the same resource simultaneously, when you try to create a resource that already exists, or when your request uses outdated version information.
The 409 status code is most common in REST APIs and collaborative editing systems where multiple clients can modify the same data. It is less common in regular web browsing because standard page loads do not modify server state. When you encounter a 409, the server is protecting data integrity by preventing a conflicting operation.
What Causes a 409 Conflict Error
Edit conflicts are the primary cause. When two users open the same document, both modify it, and the second user tries to save, the server detects that the resource has changed since the second user loaded it. Instead of silently overwriting the first user’s changes, the server returns 409 to alert the second user about the conflict. Git hosting platforms like GitHub return 409 when you try to merge branches with conflicting changes.
Resource creation conflicts occur when you try to create an entity that already exists. Attempting to register a username that is taken, creating a file that already exists on the server, or inserting a database record with a duplicate unique key all return 409. Version conflicts happen in APIs that use optimistic concurrency control: your request includes an ETag or version number that no longer matches the current version on the server.
How to Fix 409 as a User
Refresh the page to get the latest version of the resource, then reapply your changes. If you were editing a document, your changes may need to be manually merged with the changes another user made. Copy your unsaved changes somewhere safe (clipboard, text file), reload the resource, and carefully reapply your modifications to the updated version.
For username or email conflicts during registration, the value you chose is already taken. Try a different username, email address, or identifier. For file upload conflicts, rename the file before uploading or choose to overwrite the existing file if the application provides that option.
How to Fix 409 as a Developer
Implement optimistic concurrency control using ETags. When a client fetches a resource, include an ETag header in the response. When the client updates the resource, require the If-Match header with the original ETag. If the resource has changed (ETag mismatch), return 409 with the current version so the client can resolve the conflict. Include the conflicting fields and the current server values in the 409 response body to help clients auto-merge or present a conflict resolution UI.
For resource creation conflicts, include a clear error message indicating which field caused the conflict (e.g., “username already exists”) and suggest alternatives if possible. Design your API to be idempotent where feasible: if a client retries a creation request and the resource already exists with matching data, return 200 instead of 409.
Frequently Asked Questions
What is the difference between 409 and 412 errors?
A 409 Conflict means the request conflicts with the current state of the resource (edit conflict, duplicate resource). A 412 Precondition Failed means a condition specified in the request headers (If-Match, If-Unmodified-Since) was not met. Both relate to conditional requests, but 409 is about logical conflicts while 412 is about explicitly failed preconditions.
Can 409 errors happen during regular web browsing?
Rarely. Standard GET requests for web pages do not cause 409 errors because they do not modify server state. You might see 409 when submitting forms, editing wiki pages, using collaborative editors, or interacting with web applications that implement conflict detection. If you see 409 during normal browsing, the website likely has a misconfigured conflict detection system.
How should I handle 409 errors in my application?
Display a clear message to the user explaining that their changes conflict with recent updates. Show the differences between their version and the current server version when possible. Provide options to: overwrite with their changes, discard their changes and use the server version, or manually merge the conflicting sections. Auto-save the user’s work locally so they do not lose their changes during conflict resolution.
