200 OK 2xx

What does 200 mean?

A 200 OK response means the request was successful. It's the most common status code on the web by a huge margin — every successfully loaded webpage, every successful API call that returns data, every working link results in a 200.

What "successful" actually means, though, depends heavily on the request method:

• For GET, 200 means the resource was found and is included in the response body
• For POST, 200 means the action was processed and the response body typically describes the result
• For PUT/PATCH, 200 means the update succeeded, and the response often includes the updated resource
• For DELETE, 200 is less common than 204 (No Content), but when used, it typically includes a body describing the deletion

This method-dependence is easy to overlook because 200 "just works" so often that developers rarely think about what it's specifically confirming.

How a 200 behaves

• It's the default "everything is fine" signal — most frameworks return 200 automatically unless code explicitly returns something else
• It's cacheable, and in fact 200 responses to GET requests are the primary target of HTTP caching — Cache-Control, ETag, and Last-Modified headers on 200 responses are what allow browsers and CDNs to avoid re-fetching unchanged content
• The body's meaning varies by content type — an HTML page, a JSON API payload, an image, a downloaded file can all be 200 responses with completely different body structures
• It doesn't guarantee the body contains what you expect — a 200 only confirms the request succeeded, not that the business logic inside necessarily did what the client hoped (this is the root of the "200 with an error in the body" anti-pattern below)

Common scenarios worth understanding

Caching nuances:

• A 200 with Cache-Control: max-age=3600 tells clients/CDNs they can reuse this response for an hour without re-requesting
• A 200 with an ETag header lets clients send a conditional request next time (If-None-Match) — if the content hasn't changed, the server can respond with 304 Not Modified instead of sending the full body again, saving bandwidth

The "200 with an error" anti-pattern: Some APIs and applications return a 200 status code even when the requested operation failed, putting the actual error information inside the response body (e.g., { "success": false, "error": "Insufficient funds" } with a 200 status). This is widely considered poor API design because:

• HTTP-level tooling (monitoring, caching, retries) can't distinguish success from failure without parsing every response body
• It conflates "the HTTP request was processed" with "the business operation succeeded" — two different things that the status code is supposed to help separate

GET vs other methods:

• A 200 on a GET is idempotent and side-effect-free by definition — repeating it should return the same (or updated, if the resource changed) data without side effects
• A 200 on a POST/PUT/PATCH/DELETE confirms an action happened — repeating the exact same request might not be safe (e.g., resubmitting a POST that creates a record might create a duplicate, unless the API is specifically designed to be idempotent)

When 200 might not be the right choice

If you're building an API:

• For resource creation (POST that creates something new), 201 Created is more precise than 200 — it specifically signals "a new resource was created," often alongside a Location header pointing to the new resource
• For successful requests that don't return a body (e.g., a successful DELETE, or an update that doesn't need to return the updated object), 204 No Content avoids sending an empty or meaningless body with a 200
• For actual errors, use an appropriate 4xx/5xx code rather than 200 with an error flag in the body — this lets HTTP-aware tooling work correctly without custom logic

If you're calling an API:

• Don't assume a 200 means "the operation you wanted definitely happened as expected" — always check the response body's actual content for APIs that follow the "200 with error in body" pattern (unfortunately still common enough to watch for)
• For GET requests, take advantage of conditional requests (If-None-Match/If-Modified-Since) where supported, to receive 304 instead of re-downloading unchanged 200 responses

200 vs related codes

Real-world examples

Well-designed REST APIs typically reserve 200 for "request succeeded and here's the data," use 201 specifically for creation endpoints, and use 204 for actions that succeed without needing to return anything (like deletions). APIs that don't follow this convention — returning 200 for everything including failures, with success/failure indicated only in the JSON body — are common enough that "always check the body, not just the status code" is standard defensive advice for working with third-party APIs of unknown quality.

SEO implications

200 is the status code search engines want to see for indexable content — it's the unambiguous "this page exists and here it is" signal. The earlier discussion of "soft 404s" on the 404 page describes the opposite problem: pages returning 200 when they shouldn't (because the content is actually an error message). Ensuring that pages meant to be indexed return a clean 200 — with appropriate caching headers for performance — is foundational, if unglamorous, SEO hygiene.

FAQ

Does 200 mean everything about my request worked exactly as expected?

It means the HTTP request was processed successfully — but depending on the API, the response body might still contain information about a business-logic failure. Well-designed APIs use appropriate 4xx/5xx codes for actual errors, but not all APIs follow this convention, so checking the response body is still good practice.

What's the difference between 200 and 201?

200 is the general "success" code. 201 is specifically for successful resource creation — typically returned by a POST request that results in a new resource existing, often accompanied by a Location header pointing to the newly created resource.

Why would an API return 200 with no body, instead of 204?

This usually comes down to framework defaults or developer habit rather than a deliberate choice — 204 is the more semantically precise code for "succeeded, nothing to return," but many frameworks make 200 the path of least resistance, so 200-with-empty-body responses are common even where 204 would be more correct.

Is a 200 response always cacheable?

It's cacheable if the response includes appropriate caching headers (Cache-Control, ETag, Last-Modified). Without these headers, clients and CDNs typically won't cache the response even though 200 responses are generally cacheable by the HTTP spec.

Can a GET request that returns 200 still have side effects on the server?

It shouldn't, by HTTP convention — GET requests are supposed to be "safe" (no side effects) and idempotent (repeating them doesn't change anything). In practice, some poorly designed endpoints violate this (e.g., a GET request that increments a view counter or logs an action) — these side effects are usually considered acceptable as long as they don't represent meaningful state changes that a client wouldn't expect from "just reading" something.

Fun fact

200 is so dominant that it's effectively the "default" most people assume when they don't think about status codes at all — yet the full 2xx range includes several other "success" codes (201, 202, 204, 206, and more) that exist precisely because "succeeded" can mean meaningfully different things depending on what was requested.