HTTP 201 Created

Q: What does HTTP 201 Created mean?

HTTP 201 Created means the request was successful and resulted in the creation of a new resource. The Location response header should contain the URL of the newly created resource. 201 is typically returned in response to POST requests that create entities, or PUT requests that create a resource at a specific URL.

Q: When should I use 201 instead of 200?

Use 201 when a new resource was created as a result of the request. Use 200 when the request succeeded but no new resource was created — for example, a login action, a search, or an update to an existing resource. The distinction matters because 201 signals to clients that a new addressable resource exists and provides its URL in the Location header.

Q: Is the Location header required with a 201 response?

RFC 9110 says the server SHOULD include a Location header in the 201 response pointing to the created resource. It is not strictly required, but omitting it forces clients to guess or make a separate request to find the new resource. Including it is strongly recommended for REST APIs.

Q: Should a 201 response include a body?

RFC 9110 allows a 201 response to include a body representing the created resource. Including the full resource representation in the body saves the client a follow-up GET request. Many REST APIs include the created resource as JSON in the response body along with the Location header.

HTTP 201 Created means the request succeeded and a new resource was created as a result. It is the correct response for POST requests that create new entities and for PUT requests that create a resource at a specified URL. The server should include a Location header in the response pointing to the URL of the newly created resource.

HTTP 201 full guide →

Quick reference

Code	201
Name	Created
Category	2xx Success
Specification	RFC 9110 §15.3.2
IANA status	Assigned
Cacheable	No — not cached by default
Location header	Should be included, pointing to the new resource URL
In-depth guide	HTTP 201 implementation guide →

What HTTP 201 means

RFC 9110 defines 201 Created as indicating that the request was fulfilled and resulted in one or more new resources being created. The primary resource created is identified either by the Location header in the response or, if no Location is provided, by the effective request URI.

201 carries a specific semantic that 200 does not: something new and addressable now exists that did not exist before. This matters for client tooling, hypermedia APIs, and cache invalidation logic. A well-implemented REST API uses 201 consistently so clients know a new resource was created and where to find it.

The 201 response body typically contains a representation of the created resource — the same data a GET to the Location URL would return. Including the resource in the body saves the client a follow-up request. RFC 9110 permits but does not require a body with 201.

The Location header

The Location header in a 201 response contains the URL of the newly created resource. RFC 9110 says the server SHOULD include it. Omitting it forces the client to either parse the response body to extract the new resource's ID, or make a separate discovery request — both of which are unnecessary when the Location header is set.

Example 201 response with Location header:

HTTP/1.1 201 Created
Location: https://api.example.com/users/4821
Content-Type: application/json

{
  "id": 4821,
  "email": "user@example.com",
  "created_at": "2026-04-25T10:30:00Z"
}

The URL in the Location header should be absolute. The response body here mirrors what a GET to that URL would return, saving the client a round trip.

Common patterns and mistakes

Returning 200 when 201 is correct

The most common mistake is returning 200 OK from a creation endpoint. It works — the client gets its data — but it drops the semantic signal. Tools that monitor API responses, auto-generate API documentation, or handle navigation based on status codes lose the ability to distinguish creation from retrieval. Always use 201 when a new resource is created.

Omitting the Location header

A 201 without a Location header is valid per RFC 9110 but puts the burden on the client to figure out the new resource URL. If the resource ID is embedded in the response body, clients must know the URL construction rule to form the resource URL. Include Location for a self-describing response.

Returning 201 for bulk creation

When a single request creates multiple resources, the semantics of 201 become ambiguous — there is no single URL for the Location header. Common approaches are to return 200 with a body listing all created resource URLs, or to accept bulk creation as an asynchronous operation and return 202 Accepted with a status endpoint.

Using 201 for idempotent creation

A PUT request to create a resource at a known URL should return 201 on creation and 200 on subsequent idempotent puts (when the resource already exists and is updated). Returning 201 on every PUT regardless of whether the resource was created or updated incorrectly implies creation every time.

201 vs related 2xx codes

Code	Name	Use when
200	OK	Action succeeded, no new resource created
201	Created	A new addressable resource was created by the request
202	Accepted	Request received, resource creation is async and not yet complete
204	No Content	Action succeeded, nothing meaningful to return

FAQ

What does HTTP 201 Created mean?

HTTP 201 means the request succeeded and a new resource was created. The Location header should contain the URL of the new resource. It is most commonly returned by POST requests that create entities in a REST API.

When should I use 201 instead of 200?

Use 201 when a new resource was created. Use 200 when the request succeeded but nothing new was created — an update, an action, a search. The distinction provides a semantic signal that helps clients and intermediaries handle the response correctly.

Is the Location header required with a 201 response?

RFC 9110 says SHOULD, not MUST — but include it. Omitting the Location header forces clients to parse the body to find the new resource URL or make an extra request. Include it in every 201 from a REST API.

Should a 201 response include a body?

Yes, when practical. Include the full representation of the created resource in the body so the client does not need a follow-up GET. The body should match what the Location URL would return.

Related resources

On this site: HTTP 201 Created — full guide · HTTP 200 OK · HTTP 202 Accepted · HTTP 204 No Content · All 2xx success codes

Standards: RFC 9110 §15.3.2 · IANA HTTP Status Code Registry · MDN Web Docs: 201