What Is a 206 Status Code?

The 206 Partial Content status code is part of the HTTP/1.1 standard and plays a unique role in handling partial requests. While most web requests result in the server delivering the entire resource (like a complete web page, image, or video), sometimes a client only needs a specific part of that resource. That’s where 206 comes in.

In simple terms, a 206 response tells the client:
“I’ve successfully processed your request, but I’m only sending back the specific part (or parts) of the resource you asked for — not the whole thing.”
This is especially important for:
Large files like videos, PDFs, or ZIP archives
Streaming services that need to deliver data in small chunks
Download managers that resume interrupted downloads by requesting only the missing portions
Applications working over slow networks or partial data connections
Without 206, the only alternative would be for the client to re-download the entire resource, wasting time and bandwidth.
By supporting partial content delivery, 206 improves performance, saves resources, and creates smoother user experiences.

How Does a Server Respond With a 206 Status Code?

When a server sends a 206 Partial Content response, it’s handling a range request. This means the client has asked for only part of a resource — for example, bytes 500–999 of a video file — rather than the entire thing.

To fulfill this, the server needs to:

Confirm that the requested range is valid and satisfiable (i.e., it exists within the total size of the resource).
Package only the requested portion in the response body.
Include key HTTP headers that describe which part of the resource is being returned.

Here’s what a typical 206 response might look like when returning a single part:

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 2025 06:25:24 GMT
Last-Modified: Wed, 15 Nov 2025 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

This tells the client:

The server is sending bytes 21010 to 47021 out of a total 47022-byte file.
The response body contains exactly 26012 bytes — the partial content requested.

When multiple ranges are requested, the server sends a multipart response using the multipart/byteranges media type. This allows the client to reconstruct multiple requested segments. Each part includes its own Content-Range header, so the client knows exactly which range it belongs to.

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

Why Is This Important?

Partial content responses are crucial for:

Resuming interrupted downloads without restarting from zero.
Allowing media players to skip ahead in large video or audio files without buffering the entire file.
Optimizing data transfers over slow or unstable networks by breaking large files into manageable chunks.

Without this mechanism, every failed connection or skipped segment would mean redownloading huge amounts of redundant data.

Understanding Multipart 206 Responses

While a 206 Partial Content response can return just a single range (like bytes 500–999), sometimes a client requests multiple ranges at once. In this case, the server sends back a multipart/byteranges response — a special format that bundles several parts together within a single HTTP message.

Here’s an example:

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Length: 1741
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

–THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 500-999/8000

…the first range…

–THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 7000-7999/8000

…the second range…

–THIS_STRING_SEPARATES–

What’s Happening Here?

The Content-Type is set to multipart/byteranges, with a boundary string (THIS_STRING_SEPARATES) that marks where each part starts and ends.
Each part includes its own headers (like Content-Type and Content-Range), telling the client exactly what piece of the resource it’s looking at.
The client must parse each section individually to understand which ranges were returned.

Why Use Multipart Responses?

This format is useful when:
- A client requests non-contiguous byte ranges (like the first 500 bytes and the last 1000 bytes).
- The server can deliver multiple parts efficiently in one response.
- Applications need precise access to scattered pieces of a large resource, such as media files or data archives.
By bundling multiple ranges together, the server avoids sending separate responses, reducing network overhead and speeding up delivery.

When Is a 206 Status Code Used?

The 206 Partial Content status code comes into play when the client requests only a specific part of a resource, and the server is able to deliver just that portion.
This isn’t something you see on simple web pages, but it’s essential for systems that work with large files, streaming media, or resumeable downloads.

Here are the most common scenarios where a 206 response is used:

1. Resuming Interrupted Downloads
Have you ever downloaded a large file, lost your connection halfway, and then resumed without starting over?
That’s made possible by a range request and the 206 response.
Instead of downloading the entire file again, your client (such as a download manager or browser) sends a request like:

Range: bytes=500000-999999

This tells the server:

“Please send me bytes 500,000 to 999,999 — I already have the rest.”
The server then responds with 206 Partial Content and delivers just that segment.

2. Streaming Media (Audio/Video)
When watching videos online, you might skip ahead to a specific timestamp.
Behind the scenes, the video player sends a request asking for the byte range that corresponds to that time.
The server replies with a 206 response that delivers only the requested segment, allowing smooth, targeted playback without fetching the entire file.

3. Downloading Specific Segments of Large Files
Sometimes, applications or systems only need a part of a large resource — like a section of a PDF or a piece of a compressed archive.
Instead of transferring everything, they send a range request, and the server efficiently responds with only the relevant portion.

4. Optimizing Performance Over Slow Networks
On slow or unstable connections, it can be more efficient to break large transfers into small, retryable chunks.
The client requests these chunks one at a time, and the server uses 206 responses to deliver each part. This ensures minimal data loss if a connection drops.

In all these cases, 206 saves bandwidth, speeds up delivery, and improves the user experience by ensuring that only the necessary data is transferred.

Common Causes of a 206 Status Code

The 206 Partial Content response doesn’t happen by accident — it’s usually triggered by a very intentional setup between the client and server. However, several situations and configurations can lead to a 206 response, and understanding them helps developers know when and why they’re happening.

Let’s break it down.

1. Client Sends a Range Header
The most common reason for a 206 response is that the client includes a Range header in its HTTP request, specifying the exact portion of the resource it wants.
For example:

Range: bytes=0-499

This tells the server:

“I only need the first 500 bytes of this resource.”
The server checks if the requested range is valid and, if so, replies with 206 Partial Content, sending back just that piece.

2. Large File Transfers
When a server needs to deliver very large resources (like videos, software installers, or database dumps), it may choose — or be configured — to split delivery into parts, even without a specific client request.
This allows the client to process the data more efficiently, one piece at a time.

3. Network or Latency Management
Sometimes, servers are configured to break up responses because of network constraints.
For example, on slow or high-latency connections, it might be more reliable to transfer data in smaller, resumable chunks.
Partial responses reduce the risk of needing to resend entire files if a connection fails.

4. Resuming Incomplete Downloads
A partially downloaded file on the client side (due to a prior failure) can trigger a range request when the client reconnects.
This is how download managers and browsers support “resume” functions — they ask only for the missing part, and the server delivers it with a 206 response.

5. Specific Application Logic
Certain applications, especially those handling multimedia, scientific data, or partial datasets, are designed to request only portions of a file.
For example, an image processing app might only need a specific section of a huge satellite photo — the app sends a range request, and the server responds with a partial payload.

Understanding these causes helps developers and system administrators know that a 206 response is usually a sign of optimized, efficient communication between client and server, not an error or problem.

What Is the Difference Between a 206 Status Code and Other HTTP Status Codes?

The 206 Partial Content status code serves a unique purpose that sets it apart from more commonly seen HTTP responses.
Here’s how it differs from some of the most familiar status codes:

1. 206 vs. 200 OK

200 OK indicates that the server successfully processed the request and is returning the entire resource in the response body.
206 Partial Content, on the other hand, signals that the server successfully processed the request but is returning only a specific portion of the resource, as requested by the client.

Example:

Downloading an entire PDF returns a 200 OK.
Downloading just pages 5–10 of the PDF returns a 206 Partial Content.

2. 206 vs. 404 Not Found

404 Not Found tells the client that the requested resource does not exist on the server.
206 Partial Content confirms that the resource exists and the server is delivering the requested part of it.

These two are unrelated in meaning, but it’s important to note that invalid range requests can sometimes return a 416 (Range Not Satisfiable) error, not a 404.

3. 206 vs. 204 No Content

204 No Content means the server successfully processed the request but has no content to send back.
206 Partial Content means the server successfully processed the request and is sending back part of the resource.

In short, 206 always includes partial data, while 204 includes none.

4. 206 vs. 416 Range Not Satisfiable

416 indicates that the client asked for a range that can’t be fulfilled — perhaps it requested bytes beyond the size of the file.
206 means the client’s range request was valid, and the server is fulfilling it.

These differences matter because they shape how clients and servers interact, especially in complex workflows like video streaming, file downloads, and partial data transfers.
Understanding the right context for each status code ensures smooth, optimized, and error-free communication between systems.

How Do You Troubleshoot a 206 Status Code Issue?

Although the 206 Partial Content response is usually a positive sign (indicating efficient partial delivery), sometimes developers or system administrators may run into unexpected behavior related to it.
Here’s how you can approach troubleshooting:

1. Check the Network Connection
Slow or unstable network connections can sometimes lead to interrupted transfers, causing the client to repeatedly issue range requests and triggering multiple 206 responses.
Make sure the network is stable, has sufficient bandwidth, and isn’t causing premature connection drops that force partial re-requests.

2. Verify the Range Header in the Client Request
One of the most common causes of unexpected 206 behavior is a misconfigured or invalid Range header in the client’s request.
Ensure the Range header:

Specifies valid byte ranges (within the total size of the resource).
Follows proper syntax (e.g., Range: bytes=0-499).
Doesn’t request overlapping or nonsensical ranges.

3. Check Server Configuration
Confirm that the server is correctly configured to handle range requests.
Some servers (or proxies in between) may:

Disable range request support.
Strip Range headers before they reach the backend.
Have limits or thresholds that block certain partial requests.

Review server settings, proxy rules, or firewall filters that could interfere.

4. Examine Server Logs
Server-side logs are essential when diagnosing 206-related issues.
Look for:

Repeated or looping partial requests.
Unexpected coalescing or collapsing of requested ranges.
Errors that downgrade or block partial delivery.

If you see repeated 206 responses when full responses are expected, or vice versa, the logs will help reveal what’s going wrong.

5. Confirm Client-Side Handling
Not all clients handle multipart or partial responses the same way.
Make sure the client:

Is built to understand multipart/byteranges responses (if multiple parts are delivered).
Properly reconstructs the full resource when pulling multiple ranges.
Doesn’t break or misinterpret the Content-Range headers.

Testing across multiple clients or tools can help isolate whether the problem is client-side or server-side.

By systematically checking each of these areas — network, headers, server configuration, logs, and client behavior — you can troubleshoot and resolve most issues related to 206 responses.

Final Thoughts

The 206 Partial Content status code might not be as commonly discussed as 200 OK or 404 Not Found, but it plays a crucial role in optimizing modern web interactions.
It allows servers and clients to work together efficiently, especially when dealing with large files, media streams, or interrupted downloads.

Here’s why it matters:

It saves bandwidth by ensuring only the needed parts of a resource are transferred.
It improves speed and user experience, allowing users to resume downloads, jump to specific parts of videos, or request partial content on demand.
It reduces unnecessary overhead, helping servers handle large or complex resources more flexibly.

But using 206 correctly also comes with responsibility:

Servers must follow best practices when constructing partial responses.
Clients must know how to interpret Content-Range and multipart responses properly.
Developers should test edge cases, especially when dealing with multiple overlapping or complex ranges.

In summary, 206 Partial Content is a precision tool — when applied well, it can dramatically enhance performance, user satisfaction, and system efficiency.
Whether you’re a backend developer, an API designer, or a system architect, understanding and leveraging this status code can make your systems faster, smarter, and more resilient.