What Is a 226 Status Code?

The 226 IM Used status code is part of the HTTP/1.1 protocol, specifically defined in RFC3229, and it is relatively rare compared to commonly seen codes like 200 OK or 404 Not Found. This status code signals that the server has successfully fulfilled a GET request by applying one or more instance-manipulations to the current version of the requested resource.

Instance-manipulations refer to transformations applied on the server side or by an intermediary (such as a proxy or a CDN) to modify the original resource before delivering it to the client. These manipulations can include actions like delta encoding, compression, or encryption, which change the representation of the resource but not its fundamental identity.
For a server to return a 226 response, the client’s request must include an A-IM (Accept-Instance-Manipulations) header, which lists at least one manipulation the client can handle. The response from the server will then include an ETag header, identifying the entity tag of the new, transformed instance.
In short, a 226 status says:
The server is delivering a modified version of the resource, reflecting one or more transformations, as explicitly requested and accepted by the client.
While the 226 status is not widely used in typical web browsing or API operations, it plays a valuable role in optimizing content delivery when intermediaries and advanced caching strategies are involved. For example, if a server or proxy applies delta encoding to only send the differences between a cached version and the current resource, the 226 code communicates that the client should combine this partial data with prior responses to reconstruct the full resource.
Understanding this code is particularly important for developers working on systems where bandwidth optimization, distributed caching, or instance-differentiated delivery are critical.

Where Does the 226 Code Apply in HTTP?

The 226 IM Used status code applies in very specific contexts within the HTTP/1.1 protocol — mainly when the server or an intermediary (such as a proxy or content delivery network) uses instance-manipulations to optimize how resources are delivered to the client.

Let’s break this down clearly.

First, the 226 status is only valid for GET requests. When a client issues a GET request, it can include an A-IM header (Accept-Instance-Manipulations) that tells the server it can handle certain types of transformations. These might include compression, delta updates, encryption, or other forms of efficient delivery that reduce bandwidth or processing overhead.

If the server (or a proxy along the way) applies one or more of these transformations and sends back a modified resource, it signals this using the 226 status code. This lets the client know that:

The response represents a manipulated version of the resource,
The client may need to combine this response with previous or future responses to fully reconstruct the resource, depending on the manipulation.

This code is particularly useful in systems where:

Bandwidth constraints are tight (such as mobile networks or satellite links),
Large resources change incrementally over time (such as software updates or document revisions),
Intermediaries optimize delivery (such as CDNs applying compression or security transformations).

The 226 code allows the server to avoid sending the full resource each time and instead transmit only the changed or processed parts, saving time and resources for both server and client.

However, it’s important to note:

The 226 status is not used in standard web page delivery to browsers.
It is designed for specialized use cases, such as API endpoints, software distribution systems, or network optimization layers where both client and server explicitly agree on supporting instance manipulations.

Related Resources

What is a 101 Status Code?
What is a 102 Status Code?
What is a 200 Status Code?
What is a 201 Status Code?
What is a 202 Status Code?
What is a 208 Status Code?
See All Status Code

SEO Services

Other Services

Insights

Blogs

How Does the 226 Status Code Work? (Step by Step)

Understanding how the 226 IM Used status code works requires looking at the precise flow between the client, server, and any intermediaries (like proxies or CDNs) involved in the HTTP communication. Let’s walk through the process step by step.

Step 1: The client sends a GET request with an A-IM header
The client, such as a specialized application or device, makes a GET request for a resource. Importantly, this request includes the A-IM (Accept-Instance-Manipulations) header, which lists one or more types of instance manipulations the client can accept. For example, the client might specify that it can handle gzip, delta, or another manipulation.

Step 2: The server evaluates the request
When the server receives the GET request, it checks whether it can apply one or more of the requested instance manipulations to the resource. These manipulations could include compressing the resource, sending only the differences (deltas) since a previous version, or applying other optimizations.

Step 3: The server applies the manipulation(s)
If the server (or an intermediary like a proxy) decides to apply a transformation, it modifies the resource accordingly before sending it back to the client. For example, it might only send the parts of a large file that have changed, rather than the entire file.

Step 4: The server sends a 226 IM Used response
Instead of a standard 200 OK status, the server sends a 226 IM Used status in the response header. This informs the client that the returned content reflects the result of the applied instance manipulation(s), not the unmodified original resource.

Step 5: The server includes required headers
The response must include:

The ETag header, which identifies the entity tag (a unique version identifier) of the current manipulated instance.
Any IM headers that describe the manipulations actually applied, helping the client understand how to interpret or combine the response.

Step 6: The client processes the response
On receiving the 226 response, the client uses the details provided — possibly combining this response with previous responses or cached data — to reconstruct or interpret the full, current version of the resource.

Step 7: Caches handle the 226 response carefully
HTTP caches (like proxy caches or CDNs) may store 226 responses, but they must respect the standard expiration mechanisms (such as Cache-Control headers) and understand how to combine them with base instances to maintain integrity.

By following this flow, systems using the 226 status can reduce bandwidth use, accelerate data delivery, and improve efficiency — but only if both client and server (and intermediaries) fully support the required headers and combination logic.

HTTP Headers Involved: A-IM and IM Explained

The 226 IM Used status code is tightly connected to two important HTTP headers: A-IM (Accept-Instance-Manipulations) and IM (Instance Manipulations). To understand how 226 works properly, you need to understand how these headers function in both the request and response cycles.

A-IM Header (Request Side)
The A-IM header is sent by the client in its HTTP request to tell the server or intermediary what types of instance manipulations it is willing to accept.
Example:

A-IM: gzip, delta

In this example, the client indicates it can accept either a compressed (gzip) version of the resource or a delta-encoded version (containing only the differences from a known base resource).

The server uses this header to decide whether it can apply a transformation and deliver the manipulated instance instead of the full, unmodified resource.

IM Header (Response Side)
The IM header is used by the server in the HTTP response to describe what manipulations were actually applied to the returned resource.
Example:

IM: gzip

This tells the client that the server compressed the resource using gzip before returning it. The client can then decompress or otherwise process the response based on this information.

ETag Header
In any 226 response, the server must also include an ETag header, which provides a unique identifier (entity tag) for the specific manipulated instance. This helps the client — and any intermediate caches — track versions accurately and combine responses if necessary.

Cache Considerations
A 226 response can be stored by HTTP caches, but only under certain conditions:

The cache must handle the combined nature of the manipulated instance.
The cache must respect expiration and validation headers like Cache-Control and ETag.
The cache may need to combine stored data with a base resource to reconstruct the final representation.

By carefully coordinating these headers, the client and server (or intermediary) can exchange manipulated representations efficiently while preserving consistency, cacheability, and correctness.

Real-World Use Cases of the 226 Status Code

Although the 226 IM Used status code is relatively rare in everyday web interactions, it serves a valuable role in specialized scenarios where optimizing data transfer and reducing redundancy are critical. Let’s explore some real-world use cases where the 226 status and instance manipulations deliver meaningful benefits.

Content Delivery Networks (CDNs) Applying Compression
CDNs often apply compression algorithms like gzip or brotli to reduce the size of assets before delivering them to end-users. When a client indicates via the A-IM header that it accepts compressed versions, the CDN may apply the compression and return the modified resource with a 226 status, signaling that the resource has been manipulated compared to its base instance.

Proxy Servers Encrypting Web Responses
In sensitive environments, proxies may apply encryption or anonymization layers to protect data in transit. If the client supports such transformations, the proxy can send the encrypted or transformed version of the resource using a 226 response, allowing the client to decrypt or process it correctly.

Delta Encoding for Software Updates or Patches
When delivering software updates or document revisions, servers can use delta encoding to transmit only the changes (or “deltas”) between the client’s cached version and the current resource. This dramatically reduces bandwidth, especially for large files where only small portions have changed. In such cases, the server responds with 226 IM Used, indicating the response is not the full resource but the result of an instance manipulation.

Bandwidth-Constrained Networks
In mobile networks, satellite connections, or other bandwidth-limited environments, applying instance manipulations can significantly improve performance and user experience. By signaling that clients can accept compressed or partial representations, these systems can deliver efficient, manipulated resources marked with the 226 status code.

Advanced API or Microservice Architectures
Some high-performance APIs or microservices may apply backend transformations or selective delivery mechanisms to meet client needs without transmitting unnecessary data. When a client signals it can handle these optimizations, the service can apply the manipulations and return a 226 response to confirm the transformation.

In each of these use cases, the key benefit of the 226 status is efficiency: less bandwidth, faster delivery, and reduced load on servers and networks. But it also relies heavily on precise coordination between clients, servers, and intermediaries — all of which must understand and correctly implement the associated headers and manipulation logic.

Example of a 226 Response (With Headers and Curl Sample)

To make the 226 IM Used status code clearer, let’s look at a practical example showing how an HTTP request and response might look when instance manipulations are involved.

Sample Client Request

GET /large-file.json HTTP/1.1
Host: example.com
A-IM: gzip, delta
If-None-Match: "v1-resource"

In this example:

The client requests large-file.json.
It uses the A-IM header to tell the server it accepts either gzip compression or delta encoding.
It also sends an If-None-Match header with an ETag ("v1-resource") to help the server know which version the client already has.

Sample Server Response

HTTP/1.1 226 IM Used
Date: Wed, 12 Jun 2024 12:30:00 GMT
ETag: "v2-resource"
IM: delta
Content-Type: application/json
Content-Encoding: gzip
Content-Length: 1024

{ "delta": [ ...partial data here... ] }

In this response:

The server applies delta encoding (as indicated in the IM header) and sends only the parts that have changed since the v1-resource version.
It also applies gzip compression (shown in the Content-Encoding header) to further reduce the payload size.
The ETag v2-resource identifies the new state of the resource after applying the manipulations.

Testing with curl
You can simulate such a request with a curl command like:

curl -H "A-IM: gzip, delta" -H "If-None-Match: \"v1-resource\"" https://example.com/large-file.json

This command sends the headers needed to request compressed or delta-encoded responses from the server. If the server supports it, the response will include the 226 IM Used status, indicating the resource has been transformed.

This kind of exchange is powerful for saving bandwidth, reducing latency, and improving performance — but it only works when both the client and server (and any intermediaries) understand and correctly implement the HTTP headers and manipulation logic.

226 Code References in Popular Frameworks

When implementing or handling the 226 IM Used status code in applications, it’s essential to use the predefined constants or symbolic references provided by your programming framework or HTTP library.

These symbolic constants improve code readability, reduce the likelihood of hardcoding errors, and make your codebase easier to maintain and debug over time.

Here’s how the 226 status is referenced across several widely used frameworks and programming languages:

Ruby on Rails

:im_used

In Rails, this symbol maps directly to the 226 HTTP status code when building responses.

Symfony (PHP)

Response::HTTP_IM_USED

Symfony offers a clear, descriptive constant that avoids using raw numeric codes.

.NET (C#)

HttpStatusCode.IMUsed

The .NET framework provides a named enumeration value in its HttpStatusCode enum.

Rust

http::StatusCode::IM_USED

Rust’s http crate offers a clear and type-safe constant for the 226 status.

Go (Golang)

http.StatusIMUsed

In Go’s net/http package, developers can use this constant for clarity and safety.

Python (3.5 and newer)

http.HTTPStatus.IM_USED

Python’s standard library offers the HTTPStatus enum, making it easy to reference status codes by name.

Apache HttpComponents Core (Java)

org.apache.hc.core5.http.HttpStatus.SC_IM_USED

This Java library provides a symbolic constant for 226, ensuring consistency in server or client code.

Angular (TypeScript)

@angular/common/http/HttpStatusCode.ImUsed

Angular’s HTTP client module offers a ready-made constant for use in frontend applications or interceptors.

By using these framework-provided references, you improve your project’s code quality and avoid mistakes that can arise from manually typing raw status numbers. This is particularly important when handling less common codes like 226, where meaning can easily be misunderstood if not labeled clearly.

Best Practices for Using 226 Responses

Using the 226 IM Used status code effectively requires careful planning, precise implementation, and a good understanding of when it adds real value. Because this status is tied to advanced content delivery techniques, it’s crucial to follow best practices to avoid introducing unnecessary complexity or breaking client compatibility.

Here are the key best practices developers and system architects should follow when working with 226 responses:

1. Only Use 226 When Both Client and Server Support It
The client must explicitly include an A-IM header indicating that it can handle specific instance manipulations. If the server applies a transformation without confirming the client’s capability, it risks delivering a response the client cannot properly process.

Best Practice: Always check for client support before applying instance manipulations that result in a 226 response.

2. Clearly Describe the Applied Manipulations in the IM Header
The server must include an IM header in the response that lists the manipulations it actually applied (such as gzip, delta). This transparency allows the client to understand how to interpret or combine the response with cached data or other resources.

Best Practice: Always include accurate IM header values to prevent client-side misinterpretation or errors.

3. Ensure Transformations Preserve Functionality and Accessibility
Applying transformations like compression, delta encoding, or encryption should not break the resource’s functionality, accessibility, or usability. For example, compressed images must still display properly, and encrypted responses should only be sent to clients that can decrypt them.

Best Practice: Test transformed responses across all supported client types and environments.

4. Provide Access to the Unmodified Resource if Needed
There may be cases where the client needs to access the original, untransformed version of the resource — for example, for debugging, compatibility, or archival purposes.

Best Practice: Offer fallback mechanisms or alternative request methods (such as omitting the A-IM header) that allow clients to request the unmodified resource when necessary.

5. Validate Cache Behavior and Expiration Rules
Because 226 responses can be stored by caches, it’s essential that they follow HTTP caching rules properly. This includes setting accurate ETag values, honoring Cache-Control headers, and ensuring that cached manipulated resources do not accidentally replace or conflict with unmanipulated versions.

Best Practice: Thoroughly test caching interactions, especially in systems using intermediaries like CDNs or proxy servers.

Common Pitfalls and How to Avoid Them

While the 226 IM Used status code can optimize bandwidth and improve delivery efficiency, it comes with a set of potential pitfalls that developers, system administrators, and architects need to watch out for. Misusing or misunderstanding this code can lead to client errors, data corruption, or poor system performance.

Here’s a breakdown of common mistakes and how to avoid them:

1. Applying Instance Manipulations Without Client Consent
Some systems may apply compressions, deltas, or other transformations assuming all clients can handle them. But the 226 response should only be used when the client has explicitly signaled, through the A-IM header, that it understands these manipulations.

How to Avoid:
Check for the A-IM header before applying transformations. If the client hasn’t indicated support, return the unmodified resource with a standard status (like 200 OK).

2. Omitting or Misstating the IM Header in the Response
Even if the server applies manipulations, failing to include a correct IM header in the response leaves the client unable to understand what was done, potentially leading to misinterpretation or reconstruction errors.

How to Avoid:
Always include a precise IM header that matches the actual manipulations applied. For example, if you used gzip, the header must reflect that.

3. Confusing 226 IM Used With Other Similar Status Codes
Developers sometimes confuse 226 with other status codes like 200 OK (for unmodified success), 206 Partial Content (for byte-range responses), or 304 Not Modified (for cache validation). Each has distinct meanings and use cases.

How to Avoid:
Understand the clear, specific purpose of 226: it’s only used when the server has applied instance manipulations and the client has requested or allowed it.

4. Breaking Cache Integrity or Creating Inconsistent Cache Entries
Since caches may store 226 responses, incorrectly managing ETag values, Cache-Control headers, or combining manipulated and unmanipulated resources can lead to corrupted or invalid cache entries.

How to Avoid:
Follow strict cache validation and separation rules. Ensure that manipulated instances have unique ETags and that caches combine or store them according to HTTP/1.1 caching standards.

5. Skipping Testing Across All Supported Clients
Not all clients or intermediaries (like proxies) handle 226 responses equally well. Deploying 226-based optimizations without testing may break functionality for some users.

How to Avoid:
Run compatibility testing across all supported clients, browsers, libraries, and intermediaries to confirm they can properly parse and apply 226 responses.

Troubleshooting 226 Status Code Issues

While the 226 IM Used status code typically indicates that the server successfully applied requested instance manipulations, problems can arise when the client, server, or intermediaries mishandle the request or response.
Here’s a structured approach to troubleshooting when something goes wrong with 226 responses.

1. Check the Client’s A-IM Request Header
One of the first things to verify is whether the client’s request included a valid A-IM header specifying the types of manipulations it can accept (e.g., gzip, delta). Without this header, the server should not send a 226 response, and if it does, the client may not know how to handle it.

Troubleshooting Step:
Inspect the outgoing client request to ensure it includes the correct A-IM values and that they match what the server supports.

2. Confirm the Server’s IM Response Header
If the server sends back a 226 status, it must include an IM header that accurately describes the manipulations applied. Missing or incorrect IM headers can cause the client to misinterpret the response or fail to process it.

Troubleshooting Step:
Use tools like curl, Postman, or browser developer tools to inspect the response headers and verify the presence and correctness of the IM field.

3. Validate the ETag and Caching Behavior
226 responses interact with caching mechanisms, particularly when combined with base instances. If caches store or combine manipulated instances incorrectly, clients might receive outdated or corrupted data.

Troubleshooting Step:
Check that the server is providing accurate ETag headers, and ensure that cache configurations honor cache expiration and validation rules.
Clear caches if necessary to rule out stale or conflicting entries.

4. Test Client Compatibility with Applied Manipulations
Not all clients or libraries can handle all types of instance manipulations. For example, some older systems may not support delta encoding or may struggle with combined compression layers.

Troubleshooting Step:
Ensure the client application or library is designed to handle the specific manipulations listed in the IM header. If compatibility is uncertain, try disabling manipulations and requesting the unmodified resource.

5. Review Server or Proxy Configurations
If transformations are applied by a proxy, CDN, or intermediary rather than the origin server, the problem may lie in how these systems are configured. Misapplied transformations, missing headers, or improper fallback behavior can all cause issues.

Troubleshooting Step:
Audit the configurations of any intermediaries to ensure they apply transformations correctly, pass required headers downstream, and maintain protocol compliance.

Differences Between 226 and Other Status Codes (e.g., 200, 304, 206)

To fully understand the purpose and correct use of the 226 IM Used status code, it helps to compare it against other related HTTP status codes. While they may appear similar at first glance, each serves a distinct role in HTTP communications.

200 OK

Meaning: The request was successful, and the server is returning the full, unmodified resource.
Scope: Used when no special processing or manipulation was requested or applied.
Difference from 226: While 200 delivers the full resource, 226 indicates that the resource has been modified through instance manipulations (like delta or compression) requested by the client.

206 Partial Content

Meaning: The server is delivering a specific part (or range) of the resource, typically in response to a range request (such as Range: bytes=500-1000).
Scope: Used when the client only wants or needs part of a resource.
Difference from 226: 206 deals with partial content delivery (based on byte ranges), while 226 deals with transformed or manipulated full resources.

304 Not Modified

Meaning: The client’s cached version of the resource is still valid, and no new data needs to be transferred.
Scope: Helps reduce bandwidth by confirming the cache’s validity.
Difference from 226: 304 avoids sending a resource altogether when it hasn’t changed, whereas 226 sends a modified version of the resource that includes requested transformations.

Summary Table

Status Code	Purpose	When to Use
200 OK	Deliver the complete, unmodified resource	When no special transformations or partial requests are involved
206 Partial Content	Deliver only part of a resource (byte-range requests)	When the client requests specific parts of a file
226 IM Used	Deliver a transformed or manipulated version of the resource	When the client requests and supports instance manipulations
304 Not Modified	Confirm cached content is still valid, no data sent	When the resource hasn’t changed since the client’s last request

FAQ

What is the 226 IM Used status code?
The 226 IM Used status code is an HTTP/1.1 response indicating that the server has fulfilled a GET request by applying one or more instance manipulations (such as compression or delta encoding) to the resource, as requested by the client. It tells the client that the returned resource differs from the base instance.

When should you use the 226 status code?
You should use the 226 status code when a client explicitly signals support for instance manipulations via the A-IM header, and the server (or intermediary) applies one or more transformations to the resource before returning it. It is not appropriate for standard, unmodified resource delivery.

What is the A-IM header in HTTP?
The A-IM (Accept-Instance-Manipulations) header is sent by a client to indicate the types of transformations it can handle, such as gzip or delta. This informs the server or intermediary that the client is ready to receive a manipulated version of the resource, opening the door for a 226 response.

How does the 226 status affect caching?
A 226 response can be stored by HTTP caches and used alongside base instance cache entries. However, caches must carefully respect ETag, Cache-Control, and other headers to ensure manipulated and unmanipulated versions are not improperly mixed, maintaining data consistency.

What is the difference between 226 IM Used and 206 Partial Content?
The 226 IM Used code indicates the server has applied instance manipulations to a full resource, while 206 Partial Content indicates the server is delivering only a portion (byte range) of a resource. Both optimize delivery but serve different technical purposes.