HTTP Range Request Reference

Range, Content-Range, Accept-Ranges headers with byte-range syntax and 206 flow.

Reference for HTTP byte-range request headers with multi-part range syntax and server support notes, plus a live parser that resolves each range against a resource size and shows the 206 or 416 outcome.

Are byte ranges inclusive?

Yes. Both the first and last positions are inclusive and zero-based, so bytes=0-499 requests the first 500 bytes. The number of bytes returned is last − first + 1.

Fetching part of a resource

HTTP range requests let a client download just a slice of a resource — the foundation of resumable downloads, video seeking and parallel chunked transfers. The client asks with a Range header, the server answers with 206 Partial Content and a Content-Range, and advertises support up front with Accept-Ranges. This reference covers the full header set with a parser that resolves any Range value against a resource size.

How it works

A Range header names one or more byte ranges in the form first-last:

Range: bytes=0-499
Range: bytes=500-          (open-ended: 500 to the last byte)
Range: bytes=-200          (suffix: the final 200 bytes)
Range: bytes=0-499, 1000-1499   (multiple ranges → multipart/byteranges)

Positions are zero-based and inclusive. The server clamps a last value that runs past the end, treats a first at or beyond the size as unsatisfiable (416), and echoes the actual slice in Content-Range: bytes first-last/size. A single range yields one body; multiple ranges yield a multipart/byteranges response. An If-Range header makes the partial fetch conditional so a changed resource falls back to a full 200.

Tips and notes

  • Content-Length on a 206 is the size of the returned slice, not the whole file.
  • Use If-Range with the resource’s ETag to safely resume an interrupted download.
  • 416 responses should carry Content-Range: bytes */<total> so clients learn the size.
  • Only the bytes unit is widely supported; servers ignore unknown range units.