A post here:


staes that "The smallest download that browsers can do is 1K bytes."

Is this due to minimum size of a packet across the network? If not, what is the reason for this (if it is indeed true)?

  • 2
    Stick to standard terms if you want to avoid confusion. "Packet" is an IP-level term. You say "IP packet", nor "TCP packet", neither "Ethernet packet".
    – vtest
    Feb 8 '11 at 12:08
  • The sentence you quote ("The smallest download that browsers can do is 1K bytes.") is most certainly not true - there is no minimum download size; and while there is a minimum TCP/IP packet size (as explained by @DMA57361), it is certainly not 1KB. Feb 9 '11 at 14:40

Packet is an ambiguous term here because it is sometimes misused to refer to different elements for your transmission. Lets see what your data is wrapped up in and you'll see what I mean, and hopefully get the answer you wanted:

Lets assume you're sending 1 byte of data1 over the internet, on the TCP/IP model.

The data starts on the application level and needs to be wrapped up in headers for the lower levels so that it can be passed around.

First that data is wrapped in a TCP Segment, which adds a header of 20 bytes (min size now 21 bytes).
This puts us on the transport level.

This is then wrapped in an IP Packet, which adds another header of 20 bytes (min size now 41 bytes).
Now we're on internet level.
Note that this wrapping is changed each time a new router forwards your data to a new subnet.

This is wrapped in a link frame of some type - of which the header and footer size vary depending on the type of frame used, which depends on the type of link being used.
This is on link level.
This wrapping is changed each time the unit if transmitted between two entities.

Finally is the physical transmission (eg, electrical signals down a cable, radio waves, etc).

Here's some informative images available from the Wikipedia TCP/IP model page that hep to visually explain what is happening:

Data encapsulation using UDP/IP

Connection via layers in the TCP/IP model

1. I guess you might be able to send 0 bytes... but haven't checked that. In fact I haven't checked if 1 byte is allowed either, but hey.


That is incorrect, there is no minimum size for a download. You can verify this by creating a tiny file on your webserver and using wireshark to watch the network traffic when you download that file.

The minimum size of a standard ethernet packet is 64 bytes.


On the face of it, the blog posting you are quoting from is incorrect. There is no "minimum download size" for HTTP. (And your theory about minimum packet sizes is also incorrect.)

However, there is a grain of truth to this. And that is that if the size of the file you are downloading is small enough, the HTTP response message (consisting of the file and the HTTP response headers) will fit into a single network packet. If that happens, the browser is likely to get the file faster than if it took two or more packets to send the response.

(With one packet in the response, there is less chance that a packet will be dropped and need to be resent, and a greater chance that the TCP/IP flow-control window won't add extra round-trip delays for packet acknowledgment.)

The typical maximum size of a packet sent / received (the MTU) is 1500 bytes for ethernet. When you factor in the IP and TCP overheads, and the size of a typical HTTP response header, that could well leave you ~1K left for file data in the first packet of a response. Hence the grain of truth in the blogger's comment.

  • That would be correct - if you were only downloading that one image, and not, say, a webpage and its associated resources (images, JS, CSS) - in which case you're using keepalives and pipelining for multiple resources anyway, so TCP overhead and packet size are much less relevant. You are right in this particular case (downloading only one image), but how often does that happen? It seems that the blogger is stuck in 1999, where each HTTP request needed its own TCP connection. Feb 8 '11 at 16:36

It's worse than you think.

The slow page loading is because the browser is having issues rendering the 1x1 pixel 800000 times (e.g. for a browser window set to 1000x800). Many years ago, perhaps in 1999, I read an article somewhere that prescribed 16x16 as being the 'fastest' x smallest for tiling. Of course, rendering may be different now.

If you read the blog post, the complaint is actually about slow page loading. Not slow downloading. It doesn't have anything to do with packets although its been an interesting discussion.

So perhaps the question should be re-worded.

  • In that case, I may have misunderstood the blog post entirely - I've thought that the core is in this sentence: "The smallest download that browsers can do is 1K bytes [and therefore, adjust your image size to 1K]", which I've read as "...because you're transmitting 1K bytes anyway, no matter that your image is only 50 bytes" (which is an obvious nonsense). The problem here may be using "size" both for pixel dimensions and for byte count, and conflating them. Your explanation makes sense,but is irrelevant to byte count of image (contrary to what the blog says). Feb 9 '11 at 14:10
  • After re-reading the blog post, he seems to veer off course as the third paragraph is incoherent.
    – mockman
    Feb 10 '11 at 2:28
  • After re-reading your comment... His intended point is to address the problem raised in the opening paragraph. However, he mistakenly ascribes this problem to packet sizes and spends the rest of the post on it. My answer explained the reason for the slow page loading. As others have pointed out, packet characteristics aren't the cause.
    – mockman
    Aug 13 '11 at 0:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.