Runs in your browser. Your files and text never leave your device - nothing is uploaded.
2xx Success
What it means
The request succeeded and a new resource was created as a result, typically after a POST or PUT.
| Property | Detail |
|---|---|
| Status class | 2xx Success |
| Defined in | RFC 9110, Section 15.3.2 |
| Cacheable by default | Only with explicit caching headers: a cache stores it when the response carries Cache-Control (max-age, s-maxage or public) or Expires. Rarely relevant: a 201 usually answers a POST, and RFC 9110 lets a POST response be reused only with explicit freshness and a Content-Location matching the request URL. |
| Who needs to act | No one. The client should read the Location header to find what was created. |
What does HTTP 201 Created mean?
HTTP 201 Created means the request succeeded and produced at least one new resource. It is the standard reply to a POST that creates a record, or a PUT that creates a file at a new URL. The Location header identifies the new resource; if it is missing, the request URL itself is the new resource.
How 201 Created works
RFC 9110 ties 201 to two methods in particular. After a POST creates something, the server should send 201 with a Location header for the primary new resource and a body that describes it. For PUT the rule is stricter: if the target URL had no current representation and the PUT created one, the server must answer 201; if it replaced an existing one, it must answer 200 or 204 instead. An ETag on a 201 describes the representation just created, which lets the client make conditional updates later without fetching it first.
Example 201 request and response
POST /api/orders HTTP/1.1
Host: api.example.com
Content-Type: application/json
HTTP/1.1 201 Created
Location: /api/orders/9817
Content-Type: application/json
ETag: "v1"A relative Location is resolved against the request URL, so this one points to https://api.example.com/api/orders/9817.
When servers send 201 Created
- POST /users, POST /orders and similar API calls that insert a new record.
- A PUT that uploads a file or document to a URL where nothing existed before.
- WebDAV MKCOL and COPY requests that create a new collection or copy.
How to handle 201 Created
If you consume the API
- Read the Location header, or the ID in the body, instead of building the new URL yourself.
- Do not blindly retry a POST that timed out before you saw the 201. Check whether the record was created first, or send an idempotency key if the API supports one.
If you build the API
- Return 201 only when something was actually created; for an update or a no-op, use 200 or 204.
- Include Location for the primary resource and return its representation or ID in the body.
- If the work is queued rather than done, return 202 Accepted instead.
Related status codes
- 200 OK: Success without creating anything new, or a PUT that replaced an existing resource.
- 202 Accepted: The request was accepted, but the resource does not exist yet.
- 303 See Other: RFC 9110 allows it when a POST would duplicate an existing resource, pointing the client to that resource instead.
- 409 Conflict: Creation failed because it conflicts with something that already exists.
Frequently asked questions
The request succeeded and a new resource was created as a result, typically after a POST or PUT.
Returned by APIs after successfully creating a new record, file, or resource.
No fix needed - check the response's Location header or body for the new resource's identifier.
A 201 is the precise answer when a new resource was created, and RFC 9110 recommends it together with a Location header. A 200 still signals success, but clients lose the standard way of finding the new resource.
Sources
Other 2xx Success codes
Reviewed by Raja Jahangir · Last reviewed: October 7, 2026