HTTP 226 IM Used

HTTP 226 IM Used indicates that the server has fulfilled a GET request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance. Defined in RFC 3229, this status enables delta encoding — instead of sending the full resource every time, the server sends only what changed since the client's last version. This is a bandwidth optimization for resources that change incrementally, like large feeds or data files.

Debug HTTP 226 live
Analyze real 226 behavior — headers, caching, CORS, redirects
Open Inspector →

Try it (live endpoint)

Response includes the status code, standard headers (including Content-Type), and a small diagnostic JSON body describing the request and returned status.

Simulator URL (copy in the app after load — not a normal link):

https://httpstatus.com/api/status/226

Example request:

curl -i "https://httpstatus.com/api/status/226"
Try in playground

Meaning

The server has fulfilled a GET request using delta encoding. The response represents the result of one or more instance-manipulations applied to the current instance.

What it guarantees
  • The server accepted the request and produced a final response.
What it does NOT guarantee
  • The underlying business operation is correct across all downstream systems.
  • The response is cacheable unless headers explicitly allow it.

When to use this status

  • GET succeeds and returns a representation of the resource.
  • PUT/PATCH succeeds and returns an updated representation.
  • POST succeeds and returns an immediate result.

When NOT to use this status (common misuses)

Returning 200 for partial failures or errors embedded only in the body.
Clients and monitors treat it as success; failures become silent and harder to alert on.
Returning 200 for creation instead of 201 with Location.
Clients lose a reliable created-resource identifier; SDK behavior becomes inconsistent.
Returning 200 for async acceptance instead of 202.
Clients assume the work is complete and proceed incorrectly.

Critical headers that matter

Content-Type
Defines how clients parse the body.
Clients mis-parse payloads; SDKs and browsers apply wrong decoding.
Cache-Control
Controls cacheability and revalidation.
CDNs/browsers cache dynamic data or fail to cache static content.
ETag / Last-Modified
Enables conditional requests and revalidation.
Unnecessary bandwidth; poor cache consistency.

Tool interpretation

Browsers
Treats as success; caches/revalidates based on headers and validators.
API clients
Deserializes per Content-Type; conditional requests use validators when implemented.
Crawlers / SEO tools
Indexes depending on headers and canonical stability; caches behavior via validators and cache directives.
Uptime monitors
Typically marks success; advanced checks may flag header anomalies or latency.
CDNs / reverse proxies
Caches/revalidates based on Cache-Control, ETag, and Vary; compression and content-type affect behavior.

Inspector preview (read-only)

On this code, Inspector focuses on semantics, headers, and correctness warnings that commonly affect clients and caches.

Signals it will highlight
  • Status semantics vs method and body expectations
  • Header sanity (Content-Type, Cache-Control, Vary) and evidence completeness
Correctness warnings
No common correctness warnings are specific to this code.

Guided Lab outcome

  • Reproduce HTTP 226 IM Used using a controlled endpoint and capture the full exchange.
  • Practice distinguishing status semantics from transport issues (redirects, caching, proxies).

Technical deep dive

226 IM Used (RFC 3229) works with the A-IM (Accept-Instance-Manipulation) and IM (Instance Manipulation) headers. The client sends A-IM: vcdiff (or feed, diffe, etc.) along with If-None-Match to indicate the version it has. The server computes the delta between the client's version and the current version, then responds with 226, IM: vcdiff, and the delta as the body. This differs from 304 Not Modified (no change at all) and 200 OK (full representation). In practice, 226 is extremely rare — gzip compression and CDN caching have reduced the need for delta encoding. Google experimented with it for Chrome's SDCH (Shared Dictionary Compression for HTTP) but abandoned it.

Real-world examples

RSS/Atom feed delta updates
A feed reader requests a 500-item feed with A-IM: feed. The server knows the client has version X (via If-None-Match) and sends only the 3 new items since that version, wrapped in a feed format. The client merges the delta with its cached copy.
Large dataset incremental sync
A client syncs a 50MB JSON dataset daily. Instead of downloading 50MB each time, it sends A-IM: vcdiff with its cached ETag. The server computes the vcdiff and sends a 200KB delta. The client applies the patch to reconstruct the current version.
Software update diff
An application checks for updates. Instead of downloading the full 100MB binary, the update server computes a binary diff from the client's version to the latest and returns 226 with the patch. Chrome's update mechanism used a similar concept.

Framework behavior

Express.js (Node)
No built-in support. Would require middleware to parse A-IM headers, maintain version history, compute deltas (using vcdiff library), and return 226 with IM header. Extremely uncommon in Express applications.
Django / DRF (Python)
No built-in support. Django has no awareness of instance manipulations. Implementing 226 would require custom middleware to intercept responses, cache representations, and compute deltas.
Spring Boot (Java)
No built-in support. Would require custom HandlerInterceptor to detect A-IM headers, retrieve previous versions, compute deltas, and set the 226 status with IM header.
FastAPI (Python)
No built-in support. FastAPI has no delta encoding support. If needed, implement as middleware: compare request's If-None-Match with current ETag, compute delta, return Response(status_code=226, headers={'IM': 'vcdiff'}).

Debugging guide

  1. 226 is extremely rare in the wild — if you encounter it, you're likely working with a specialized system
  2. Check the IM response header to understand what instance manipulation was applied (vcdiff, feed, etc.)
  3. The client must understand how to apply the instance manipulation to its cached representation
  4. If the delta is larger than the full resource, the server should fall back to a normal 200 response
  5. Verify the client's A-IM header matches a manipulation the server supports

Code snippets

Node.js
// Conceptual delta encoding with 226 IM Used
const vcdiff = require('vcdiff');

app.get('/api/dataset', (req, res) => {
  const acceptIM = req.headers['a-im'];
  const clientETag = req.headers['if-none-match'];
  const current = getDataset();
  const currentETag = computeETag(current);

  if (clientETag === currentETag) {
    return res.status(304).end(); // Not Modified
  }

  if (acceptIM?.includes('vcdiff') && clientETag) {
    const previous = getCachedVersion(clientETag);
    if (previous) {
      const delta = vcdiff.encode(previous, current);
      return res.status(226)
        .set('IM', 'vcdiff')
        .set('ETag', currentETag)
        .send(delta);
    }
  }
  // Fallback: full response
  res.set('ETag', currentETag).json(current);
});
Python
# Conceptual 226 IM Used implementation
from fastapi import Request, Response

@app.get('/api/dataset')
async def get_dataset(request: Request):
    accept_im = request.headers.get('a-im', '')
    client_etag = request.headers.get('if-none-match')
    current = get_current_dataset()
    current_etag = compute_etag(current)

    if client_etag == current_etag:
        return Response(status_code=304)

    if 'vcdiff' in accept_im and client_etag:
        previous = get_cached_version(client_etag)
        if previous:
            delta = compute_vcdiff(previous, current)
            return Response(
                content=delta, status_code=226,
                headers={'IM': 'vcdiff', 'ETag': current_etag})

    return Response(content=json.dumps(current),
                   headers={'ETag': current_etag})
Java (Spring)
// Conceptual 226 implementation in Spring
@GetMapping("/api/dataset")
public ResponseEntity<byte[]> getDataset(
        @RequestHeader(value = "A-IM", required = false) String acceptIM,
        @RequestHeader(value = "If-None-Match", required = false) String clientETag) {
    byte[] current = datasetService.getCurrent();
    String currentETag = computeETag(current);
    if (currentETag.equals(clientETag)) {
        return ResponseEntity.status(304).build();
    }
    if (acceptIM != null && acceptIM.contains("vcdiff") && clientETag != null) {
        byte[] previous = versionCache.get(clientETag);
        if (previous != null) {
            byte[] delta = VCDiff.encode(previous, current);
            return ResponseEntity.status(226)
                .header("IM", "vcdiff").header("ETag", currentETag)
                .body(delta);
        }
    }
    return ResponseEntity.ok().header("ETag", currentETag).body(current);
}
Go
func datasetHandler(w http.ResponseWriter, r *http.Request) {
	acceptIM := r.Header.Get("A-IM")
	clientETag := r.Header.Get("If-None-Match")
	current := getCurrentDataset()
	currentETag := computeETag(current)

	if clientETag == currentETag {
		w.WriteHeader(304)
		return
	}
	if strings.Contains(acceptIM, "vcdiff") && clientETag != "" {
		if prev, ok := versionCache[clientETag]; ok {
			delta := computeVCDiff(prev, current)
			w.Header().Set("IM", "vcdiff")
			w.Header().Set("ETag", currentETag)
			w.WriteHeader(226)
			w.Write(delta)
			return
		}
	}
	w.Header().Set("ETag", currentETag)
	w.Write(current)
}

FAQ

Is HTTP 226 IM Used actually used in practice?
Extremely rarely. It was defined in 2002 (RFC 3229) but never gained widespread adoption. Google experimented with SDCH (a delta encoding scheme) in Chrome using 226, but removed it in 2017. Most applications use gzip compression and CDN caching instead. You're unlikely to encounter 226 unless working with specialized enterprise or scientific data systems.
How is 226 different from 304 Not Modified?
304 means 'nothing changed at all — use your cached copy.' 226 means 'something changed, and here's the delta between your version and the current version.' 304 sends no body; 226 sends a delta/patch that the client applies to its cached copy to reconstruct the current version.
What instance manipulations are defined?
RFC 3229 defines several: 'vcdiff' (binary delta), 'diffe' (unified diff), 'gdiff' (generic diff), 'identity' (no manipulation), and 'feed' (for syndication feed deltas). Implementations can define custom instance manipulations. In practice, vcdiff was the most commonly referenced.
Why didn't 226 become popular?
Several factors: (1) gzip compression already reduces bandwidth significantly, (2) CDNs serve cached full responses fast enough that deltas aren't needed, (3) maintaining version history for delta computation is complex and memory-intensive, (4) HTTP/2 header compression and multiplexing reduced the overhead of full responses, (5) most web resources either don't change often (use 304) or change completely (gzip is sufficient).

Client expectation contract

Client can assume
  • A final HTTP response was produced and processed by the server.
Client must NOT assume
  • The change is durable across all downstream systems.
Retry behavior
Retries are generally unnecessary; treat as final unless domain rules require revalidation.
Monitoring classification
Success
Use payload and header checks to avoid false positives; cacheability depends on Cache-Control/ETag/Vary.

Related status codes

208 Already Reported
The members of a DAV binding have already been enumerated in a previous reply to this request.
300 Multiple Choices
The request has more than one possible representation. The client should choose one (rarely used in practice).

Explore more

Related tools
Related utilities