201 Created
2xx success
The request created a new resource, usually identified by the Location header.
201 tells the client that something new now exists. The response should include a Location header pointing at the new resource's URL, and the body usually returns its representation — including server-assigned fields such as the id and timestamps — so the client doesn't need a second request.
| Class | 2xx Success |
|---|---|
| Retry? | Not applicable |
| Cacheable by default | No — only with explicit Cache-Control |
| Response body | Allowed |
| Defined in | RFC 9110 §15.3.2 — 201 Created |
HTTP/1.1 201 Created Location: /users/42 Content-Type: application/json
When you'll see it
- A POST to a collection created an item (
POST /users→/users/42). - A PUT created a resource at a URL that didn't exist before. Updating an existing one returns 200 or 204.
How to use it well
- Set
Locationto the new resource's URL. - Return the created object in the body — clients almost always need the generated id.
- If creation is queued and happens later, use 202 Accepted instead.
Send a 201 from your server
res.set("Location", "/users/42");
res.status(201).json(result);return Response.json(result, { status: 201, headers: { "Location": "/users/42" } });return result, 201, {"Location": "/users/42"}w.Header().Set("Location", "/users/42")
w.WriteHeader(http.StatusCreated)add_header Location "/users/42" always; return 201;
Check what a URL returns
Print just the status line from the command line, or check a whole list of URLs at once, with their response headers, in the HTTP Status Checker.
curl -sI https://example.com/your-path | head -n 1
Frequently asked questions
201 or 200 for a POST?
201 when the POST created a resource you can address afterwards. 200 when it performed an action — sending an email, running a search — that didn't create anything.
Is the Location header required?
Not strictly: RFC 9110 says the new resource is identified by Location if present, otherwise by the request URL. In practice, always send it.