206 Partial Content 2xx

What does 206 mean?

A 206 Partial Content response means the server is sending only part of a resource, in response to a Range header in the request — and that part is exactly what was asked for. It's the success counterpart to 416 (Range Not Satisfiable): where 416 means "that range doesn't correspond to anything in this resource," 206 means "here's the portion of the resource you asked for."

206 is the engine behind a huge amount of everyday web functionality that users never think about as "HTTP status codes" — video scrubbing/seeking, resumable downloads, and adaptive streaming all rely on 206 responses to fetch specific byte ranges of larger files.

How a 206 behaves

• It includes a Content-Range header specifying which portion of the resource is included (e.g., Content-Range: bytes 200-1023/2048) and the resource's total size
• It includes only the requested bytes in the body, not the full resource
• It's cacheable under appropriate conditions, similar to 200, with caches needing to handle partial-content caching correctly (a more complex caching scenario than whole-resource caching)
• Multiple ranges can theoretically be requested and returned in a single response using multipart/byteranges, though single-range requests are far more common in practice

Common scenarios

If you're building the API or website:

• You're serving large media files (video, audio) and want to support seeking/scrubbing — implementing range request support (returning 206 for valid Range requests) is essential for this
• You're supporting resumable downloads for large files — a download manager can request "the rest of the file starting from byte X" after an interruption, receiving 206 with just that remaining portion
• Most modern web servers and CDNs handle range requests for static files automatically — if you're serving files through standard mechanisms, 206 support may already be present without explicit implementation

If you're calling an API:

• You're implementing a download manager, media player, or similar tool that needs to fetch specific portions of a file — sending Range headers and handling 206 responses (vs. 200 for full responses, vs. 416 for invalid ranges) is core to this functionality

If you're a website visitor:

• Every time you skip ahead in a video, pause and resume a large download, or a media player loads "just enough" of a file to start playing without downloading the whole thing — 206 responses are very likely involved behind the scenes

206 vs 200 vs 416

Real-world examples

Video streaming platforms rely heavily on range requests — when you seek to a specific point in a video, the player calculates which byte range corresponds to that point and requests it via Range, receiving 206 with just that segment rather than the entire video file. Package managers and download tools that support resuming interrupted downloads use Range requests to fetch only the remaining portion of a file after a connection drop, receiving 206 for the remainder rather than re-downloading the entire file from scratch.

SEO implications

206 is relevant to media file delivery (video, audio, large downloads) rather than HTML page content — search engines crawling and indexing page content typically receive full 200 responses for HTML, while range requests are a separate mechanism primarily used by media players and download tools, not by crawlers indexing text content.

FAQ

What's the difference between 200 and 206?

200 means the full resource is in the response. 206 means only a specific portion (byte range) is included, as requested via a Range header — the rest of the resource exists but wasn't included in this particular response.

How does video seeking use 206?

When you click to a different point in a video's progress bar, the player calculates the approximate byte position corresponding to that timestamp and sends a Range request for that portion of the video file, receiving 206 with just that segment — allowing playback to jump to that point without downloading everything before it.

Does every server support range requests (206)?

Most modern web servers and CDNs support range requests for static files (videos, downloadable files) by default. Dynamically-generated content may or may not support ranges depending on the application's implementation — it's not automatic for everything, particularly for content generated on-the-fly rather than served as static files.

What does the Content-Range header look like on a 206 response?

Something like Content-Range: bytes 200-1023/2048 — indicating this response contains bytes 200 through 1023 (inclusive) of a resource that's 2048 bytes total.

Can caching work correctly with 206 responses?

Yes, but it's more complex than caching full 200 responses — caches need to track which specific byte ranges of a resource they have cached, and potentially combine multiple cached ranges to serve different range requests, rather than treating the resource as a single cacheable unit.

Fun fact

206, alongside Range/Content-Range/Accept-Ranges headers and 416, forms HTTP's built-in "partial transfer" toolkit — a feature set that's been part of the protocol since HTTP/1.1 (1997) and that quietly underpins an enormous amount of how video, audio, and large file delivery work across the modern internet, despite predating the explosion of online video by roughly a decade.