206 Partial Content
The server is returning only the byte ranges the client asked for in the Range header.
Status
HTTP/1.1 206 Partial Content
Details
- Category: 2xx
- Status: Standard. Registered with IANA and defined by a current standards-track RFC.
- Specification: RFC 9110 §15.3.7
- Cacheable: Cacheable by default
- Response body: Allowed
- Retry: Safe to retry
206 powers resumable downloads and media seeking. The client sends Range: bytes=start-end, the server answers 206 with just that slice and a Content-Range header describing which slice it is and how large the whole representation is. Video players use this constantly to jump around a file without downloading it.
A multi-range request produces a multipart/byteranges body with one part per range. If the requested range is outside the size of the resource, the correct answer is 416 rather than 206.
Headers
- Content-Range: Required. Describes the returned range and total size, e.g. bytes 0-1023/146515.
- Accept-Ranges: Advertised on earlier responses to tell clients range requests are supported.
- ETag: Lets the client send If-Range so a changed resource restarts rather than stitching mismatched bytes.
Common causes
- A download manager or client resumed an interrupted transfer.
- A video or audio player seeked to a position in a media file.
- A tool such as curl was given a range flag explicitly.
How to fix it
As the client
- Use If-Range with the ETag when resuming, so you never splice bytes from two different versions of a file.
- Validate Content-Range against what you asked for before appending to a local file.
As the server
- Advertise Accept-Ranges: bytes on full responses if range support exists.
- Return 416 for unsatisfiable ranges rather than silently sending the whole body.
- Make sure the CDN or proxy in front of the origin passes Range through rather than collapsing it into a full fetch.
Examples
GET /video/clip.mp4 HTTP/1.1 Host: media.example.com Range: bytes=1048576-2097151 HTTP/1.1 206 Partial Content Content-Type: video/mp4 Content-Range: bytes 1048576-2097151/52428800 Content-Length: 1048576
Notes for proxy users
Range requests are the cheapest way to test throughput through a proxy without pulling an entire file, and they let a scraper fetch just the header bytes of a large asset to identify it.