chain
#
HTTP 409 Conflict
⌃⏎ run · clear · / focus input
Meaning
send output to
no matches
Result appears here as you type
runs in your browser · nothing uploaded
// about this tool

HTTP 409 Conflict Online

Updated 2026-07-26

HTTP 409 Conflict means your request is valid and well-formed, but applying it right now would clash with the resource's current state — a duplicate email on signup, or an update based on data that's since changed underneath you. The request itself isn't the problem; the timing or state is.

The fix is almost always to re-fetch the current state before retrying: check whether the resource already exists (for a create) or whether the version you're updating is stale (for an edit), then reconcile and resend. Simply repeating the same request will just produce the same 409 again. For every other status code at once, use the full HTTP Status Codes reference.

// how to use

  1. 1 The code is already looked up below — 409 is pre-filled.
  2. 2 Type any other status code to look that one up instead.
  3. 3 Copy the result, or use the full HTTP Status Codes reference for every code at once.

// examples

The code itself
Input
409
Output
409 Conflict — Client Error (4xx). The request conflicts with the current state of the resource.
A code it's sometimes mistaken for
Input
400
Output
400 Bad Request — the request itself is malformed, unrelated to the resource's current state.

// common uses

Handling a duplicate-resource error (e.g. an email already registered) Implementing optimistic locking / version-conflict detection in an API Distinguishing a state conflict (409) from a malformed request (400) Checking what a status code in server logs actually means

// faq

Is anything uploaded to a server?
No. The lookup runs entirely in your browser from a built-in table, so nothing you type leaves your machine.
What's a typical example of a 409?
Trying to create a user account with an email that's already registered, or trying to update a record that someone else has changed since you last read it — the request is valid, but it clashes with what's already there.
How is 409 different from 400 Bad Request?
400 means the request is malformed on its own — bad JSON, missing fields. 409 means the request is perfectly well-formed, but applying it right now would conflict with the resource's current state (a duplicate, a stale version, a locked record).
Is 409 used for optimistic-locking / version-conflict scenarios?
Yes, commonly — many APIs return 409 when a client tries to update a resource using a stale version identifier (an ETag, a version number), signalling the client should re-fetch the latest state before retrying.
What should a client do after getting a 409?
Usually re-fetch the current state of the resource, reconcile the difference (or ask the user to), and retry — simply resending the same request again will just produce the same conflict.

Use this via API

Get a free API key →
curl -X POST https://thesnaptools.com/api/v1/tools/http-409 \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"text":"409"}'
Esc
↑↓ navigate open Esc close