HTTP range requests: what a Range header asks for, and what comes back

What an HTTP range request is

A range request asks a server for part of a file rather than all of it. It is how a video player seeks to the middle of a recording without downloading the beginning, how a download resumes after a dropped connection, and how a PDF viewer renders page 400 of a large document without fetching pages 1 to 399. The client sends a Range header naming the byte offsets it wants; a server that obliges answers 206 Partial Content with just those bytes and a Content-Range header saying which ones they were.

The syntax is a range unit, an equals sign, and one or more ranges separated by commas. Only one unit is defined — bytes — and offsets are inclusive and start at zero, so bytes=0-499 is the first five hundred bytes and bytes=500-999 is the next five hundred. The end offset can be left off, which means everything from there to the end.

The form that catches people out is the one with nothing before the hyphen. bytes=-500 is not an error and not an offset of minus five hundred: the specification calls it a suffix range and defines it as, in its own words, the last N units of the representation data. So it asks for the final five hundred bytes, and bytes=0-0,-1 asks for the very first byte and the very last one, which is the specification's own example.

How to use it

1. Type a Range header and a file size. The header goes in as you would send it, with or without spaces after the commas — the specification's own examples include them. The size is the length of the whole file, because every offset is worked out against it.
2. Read the status row. 206 means the ranges were honoured, 416 means none of them could be, and the tool shows the Content-Range each answer would carry. The sample buttons cover a suffix range, a plain one, a two-part request and one that falls past the end of the file.
3. Look at the table. It lists the exact first and last byte of every part that would arrive, its size, and the Content-Range that part carries. Underneath, the findings explain anything the specification says about what you asked for.

The server is allowed to ignore you

This is the first thing worth internalising, and it is stated plainly: a server may ignore the Range header field. Not reject it, not error — ignore it, and reply 200 with the whole file as though the header had never been sent. That is a conforming response, so any client that requests ranges has to handle a complete body arriving instead of a partial one.

The specification repeats the point from the other side when it discusses 416, noting that because servers are free to ignore Range, many implementations will respond with the entire representation in a 200, and concluding that clients cannot depend on receiving a 416 even when it is most appropriate. If your resume logic treats anything other than 206 as a failure, it will break against a perfectly conforming server.

The scope is narrower than most people assume, too. Range handling is defined for exactly one method: a server must ignore a Range header on a request whose method is unrecognised or for which range handling is not defined, and GET is the only method the specification defines it for. A Range on a POST is required to do nothing.

One range and two ranges are different responses

Ask for a single range and you get 206 with that range as the body and a Content-Range header at the top of the response saying which bytes and out of what total. Ask for two, and the shape changes completely: the server must send multipart/byteranges content, with a boundary parameter on the Content-Type, and each range arriving as its own part with its own headers.

Here is the rule that surprises almost everyone, and it is a MUST NOT rather than a matter of taste: a server must not put a Content-Range header in the header section of a multiple-part response, because that field goes inside each part instead. Code that reads Content-Range off the response to work out what it got will read nothing at all the moment a second range is added. The prohibition runs the other way too — a server must not wrap a single range in multipart framing, since a client that asked for one part might not be able to parse multipart at all.

Two more permissions are worth knowing before you send a long list. A server may coalesce ranges that overlap, or that are separated by a gap smaller than the cost of sending them separately, and it may do so regardless of the order they appeared in your header — so what comes back need not match what you asked for, in count or in sequence. And the framing is not free: the specification puts the overhead between parts at around eighty bytes, and observes that transferring many small disjoint parts can be less efficient than transferring the whole representation. The tool adds that up for you and says so when it happens.

What this will not tell you

This works out what a header means. It does not talk to your server. A browser cannot issue a cross-origin request and read the response headers back for you without the server's cooperation, so nothing here is fetched — the file size is the number you typed, not one that was measured. To see what a real server does, use your browser's network panel or a command-line request with the header set by hand.

It also cannot tell you whether the server supports ranges at all. That is advertised with an Accept-Ranges header on an ordinary response, and since a server may ignore Range regardless, the only certain answer is to ask for a range and see what comes back. A 206 means yes; a 200 means either no, or yes-but-not-this-time.

There is one simplification in the arithmetic. Byte offsets in HTTP have no upper bound, and the specification explicitly warns recipients to anticipate potentially large decimal numerals and to prevent parsing errors from integer overflow. This page works in ordinary JavaScript numbers, which are exact up to about nine quadrillion — far beyond any real file, but not unbounded, so a deliberately enormous offset will lose precision here in a way a careful server would not.

Finally, conditional range requests are out of scope. A real resume normally pairs Range with If-Range so the server can check the file has not changed underneath you and send the whole thing if it has. That interaction is a separate mechanism with its own rules, and this page answers only the question of which bytes a given Range names.

Why is it free?

Parsing a header and doing arithmetic on byte offsets runs in your browser. There is no server in the loop, so there is nothing to bill for and no account to create.

Nothing is uploaded and nothing is fetched. Reload the page and it has forgotten what you typed.