Does downloading an image off a website, when Wi-Fi is strong, result in a higher-quality image on your device?

  • 35
    \$\begingroup\$ Although the answers below are correct, please note that some services e.g. Facebook or Whatsapp, might process the image to reduce the filesize. This might (most likely will in most cases) affect the quality of the image as it's not the same image you uploaded on the other end. \$\endgroup\$ Commented Jun 11, 2019 at 8:44
  • 1
    \$\begingroup\$ @HagenvonEitzen some mobile networks did fairly recently recompress (over http but not https). This could, for example, render the text illegible on maps - exactly the sort of thing you might want to use 3G for! \$\endgroup\$
    – Chris H
    Commented Jun 11, 2019 at 21:03
  • 14
    \$\begingroup\$ obligatory xkcd \$\endgroup\$ Commented Jun 12, 2019 at 4:48
  • 2
    \$\begingroup\$ Strictly still images or also video? \$\endgroup\$ Commented Jun 13, 2019 at 12:57
  • 1
    \$\begingroup\$ The wifi itself has checks and balances, and TCP has checksums. However, if the other end detects a condition it can swap the content with a different version of the same file. \$\endgroup\$
    – cybernard
    Commented Jun 13, 2019 at 14:43

8 Answers 8


Does downloading an image off a website when WiFi is strong result in a higher quality image on your device?

Signal quality does not usually affect the transmission of data that is sent, though it might result in incomplete transmission. However...

  • Websites often send different data to mobile vs desktop.

  • Some sites do use scripting to send different data depending on link quality and speed. This is especially common on video streaming sites.

  • Some browsers use proxy servers to accelerate transmission speed by compressing data. This may include lossy recompression and resizing of images.

  • Some sites may display a more highly compressed image than they send for download. This is often the case when a zoom function is present.

  • 9
    \$\begingroup\$ When I was a kid, my parents hard a PCMCIA mobile data card and the provider would compress all images - including icons - before putting them through. The compression was quite aggressive. \$\endgroup\$ Commented Jun 12, 2019 at 8:52
  • 4
    \$\begingroup\$ Some network providers (both WiFi and cell data) intercept traffic and reduce the image quality to save bandwidth. \$\endgroup\$
    – OrangeDog
    Commented Jun 12, 2019 at 10:25
  • 6
    \$\begingroup\$ @OrangeDog yet another reason to ensure the sites you visit use TLS (HTTPS) when it is available. \$\endgroup\$
    – Seth R
    Commented Jun 12, 2019 at 19:08
  • 1
    \$\begingroup\$ @SethR That depends whether you'd prefer the higher quality or faster loading. The reason for TLS is because they might be doing other less innocuous things with your traffic. Or even well-intentioned things that don't work properly. \$\endgroup\$ Commented Jun 13, 2019 at 23:22
  • 1
    \$\begingroup\$ Also, some sites (e.g. Google Image Search) may have a low-quality placeholder while it waits to receive the larger image (and this process may not complete for one reason or another). \$\endgroup\$
    – NotThatGuy
    Commented Jun 14, 2019 at 11:29

The other answers point out that the quality of digital images does not deteriorate during transfer. It is worth pointing out that many mobile data plans these days, however, transcode at least movies and deliver them with lower quality than the original if they are transferred via a channel accessible to the service provider. That can either mean non-encrypted transfer or transfer of an encrypted channel for which the service provider has a caching arrangement with the content provider (typical for platforms like Netflix). Depending on the plan and its provider, non-encrypted images on web sites may be equally afflicted.

With such a data plan, being connected via WiFi would increase the typical image quality. The result would not vary depending on the quality of the WiFi connection but on whether the phone uses it at all instead of relying on the possibly recoding mobile data plan.

So in principle the quality of images does not depend on the quality of the channel used for getting them but on whether somebody messes with your data. And these days, they may.

  • 8
    \$\begingroup\$ Also, for that matter most streaming services adjust quality (resolution, compression level) based on connection speed and quality. (Regardless of any ISP interaction.) \$\endgroup\$
    – mattdm
    Commented Jun 11, 2019 at 12:48
  • \$\begingroup\$ @mattdm and often (for example tmobile does this with binge on) they'll just throttle your connection to youtube/netflix/etc and let the app decide to stream at a lower quality. \$\endgroup\$
    – Jon
    Commented Jun 11, 2019 at 20:36
  • 1
    \$\begingroup\$ @Jon Optus also does this when you have free video streaming turned on, but it really doesn't work well and severely messes with the auto quality system for both Netflix and Stan. It'll start streaming at a low quality and progressively increase the quality until it finally reaches a 720p or 1080p, then within a few senconds Optus throttles the connection and the streaming buffers and drops back to the lowest quality. Crappy system. \$\endgroup\$
    – Clonkex
    Commented Jun 11, 2019 at 23:45
  • \$\begingroup\$ "an encrypted channel for which the service provider has a caching arrangement with the content provider" – How can you do this without the encryption keys? \$\endgroup\$
    – xiota
    Commented Jun 12, 2019 at 5:00
  • 1
    \$\begingroup\$ @xiota Simple: the service provider has the encryption keys. They're acting as a CDN in this case. security.stackexchange.com/questions/107835/… \$\endgroup\$
    – mattdm
    Commented Jun 12, 2019 at 15:30

Even though the other answer here are already very good, allow me to give a different perspective:

In general, no.

When you download an image in your browser, it is very likely that this file (the image) will be downloaded through the Transfer Control Protocol (TCP). TCP will split up your image in little packets, and send each of those separately over the internet. Each packet is accompanied by a checksum. This checksum is the result of a certain mathematical operation on the packet. Once received, the checksum is calculated again by the receiver. Both checksums should be the same. If not, that means at least one bit has changed or information was left behind. In this case the receiver will request to send that particular packet again. Once all packets have been received, the downloaded file will be identical to the original on the server you downloaded it from.

However, you're streaming a movie, or viewing images over a webstream, chances are that it is not TCP, but UDP(User Datagram Protocol). UDP does NOT do the same checks as TCP does. it is called "fire and forget". If packets get lost or damaged, they will not be repaired.

  • 5
    \$\begingroup\$ Also, bit errors (not intentional lossy transcoding) would noticeably break images in most formats. Most widely-used formats are compressed, with the outer-most layer of compression (outside the lossy quantization or lossless processing) being some kind of entropy coding (like Huffman for JPEG, or zip aka DEFLATE for PNG) where changing 1 bit in the bitstream may induce big changes in how the rest decodes. For video formats, this might just be a single corrupted 8x8 macroblock or something. \$\endgroup\$ Commented Jun 11, 2019 at 23:43
  • 2
    \$\begingroup\$ Now that everyone has moved away from Flash to HTML5, streaming sites are more likely using TCP. See Does YouTube stream Videos via TCP? \$\endgroup\$
    – xiota
    Commented Jun 12, 2019 at 2:11
  • 3
    \$\begingroup\$ UDP also uses checksums. You will lose whole packets, not single bits. \$\endgroup\$
    – Dubu
    Commented Jun 12, 2019 at 8:29
  • \$\begingroup\$ @Dubu: The checksums are provided for the application layer. UDP itself does not provide any correction or even detection at all. TCP uses packets, UDP does not. \$\endgroup\$
    – Opifex
    Commented Jun 13, 2019 at 7:01
  • \$\begingroup\$ @Opifex No. TCP has streams, UDP has datagrams, but both have packets (or rather, they're there on a lower level). But UDP does guarantee data integrity (as much as the checksum can) - you'll never get a broken datagram, or an incomplete/fragmented datagram. UDP will not retransmit broken datagrams - as far as your application is concerned, they never made it. \$\endgroup\$
    – Luaan
    Commented Jun 14, 2019 at 8:15

No, computers communicate on a bit-perfect level -- even a slight change during transmission might completely corrupt the data, and is protected against using checksums (and retries in case of errors).

However, it's possible to have "progressive loading" of images, where e.g. a website might first display lower-resolution images as a quick placeholder (to reduce the perceived load speed), replaced by the higher-resolution images once they have been downloaded. If your connection is really slow and/or unreliable, it is possible that you would get stuck with the lower-resolution placeholder image.

Edit: To clarify, it's possible that the quality may be reduced due to a number of factors, but it's because the web page (or a proxy) chooses so -- not because of transmission over wifi would deteriorate the quality.

  • 3
    \$\begingroup\$ It's true that data transfers over HTTP are lossless, but there are certainly sites that will hack/optimize image and other resource loading. If images take too long to load, they won't load higher resolution versions in the future. This is actually becoming standardized, with the browser reporting the measured bandwidth (based on recent throughput) to the page so that the page can decide what to do. It's also possible for some WiFi connections to get flagged as metered connections, where sites may optimize for low bandwidth. \$\endgroup\$
    – Brad
    Commented Jun 11, 2019 at 19:27
  • 3
    \$\begingroup\$ Web sites certainly optimize their images like that, but it's usually the client side that makes the judgement to request a proper image from the server. If you plain download an image off the server, it certainly won't know how strong a wifi you're on, and as such won't change the quality of the image based on that (as asked in the original question). \$\endgroup\$
    – vlumi
    Commented Jun 11, 2019 at 22:33

The other answers are correct (no loss in quality of images over WiFi), but I just want to point out:

You may have seen that the quality of streaming(!) videos seems to degrade on 'weak' connections. This is however not caused by some of the information being lost during transmission(*): Most video streaming servers today maintain multiple copies of the same video, each compressed with a different compression ratio. Higher compression ratios yield smaller files, but because the compression is lossy the quality of those smaller files is worse.

Now, what happens while you stream a video is that the streaming server monitors the 'quality' of your connection, i.e. the data rate of the connection. When the server detects that your connection has become slower, e.g. because you moved your device and the WiFi signal becomes marginal, it will more or less seamlessly switch to a lower bitrate stream of the same video, sacrificing image quality for being able to continue watching the video instead of having the (high quality) video pause repeatedly while the next few seconds of the stream are downloaded.

This works the other way around too: When the server detects that your connection's bandwidth increased, it may switch to a higher quality version of the stream trying to always give you the best image quality possible with your current bandwidth.

*) Actually, it is indirectly caused by loss of data packets: When the signal becomes weak, random data errors become more frequent. However, these data errors are detected by the hardware and 'broken' packets will usually be sent again a number of times until the packet is received correctly; this however means that each packet needs (on average) to be transmitted over the WiFi link more than once, e.g. three times, which means that the achieved data rate (i.e. packets successfully transferred per second) drops to e.g. 1/3.


To add a bit more flavor to these other answers, here's several copies of a picture that I just took:

Unikitty 1 - Resized ?x400px, no change in quality

Unikitty 1

Unikitty 2 - Resized ?x400px Quality 50%

Unikitty 2

Unikitty 3 - Resized ?x200px Quality 50%

Unikitty 3

Unikitty 4 - Resized ?x200px Quality 5%

Unikitty 4

On my computer I have stripped the metadata with exiftool --all=, and computed checksums of the images:

$ sha256sum unikitty*.jpg
2ead7f2b1c5453f2a80da46f131c95be3423fc92ef8bce43b95fac3ee483d1b3  unikitty.jpg
42358f2f2447568fedc31a03575e8850406f89ff0e5d5a6e2d15c9e492205279  unikitty1.jpg
5c05365cb4aea2f100da471cdee85e5a3942509ab09cf3aa646fddb6962bd95a  unikitty2.jpg
e48c7158bbb9476cacdc80308832d76384e3016fb4dd2afd4333970781b367d5  unikitty3.jpg
986f8c64745fb61196df662c5e9a7c799ed370749f3dc367f269162bfa413800  unikitty4.jpg

However, when I download Unikitty #4, the hash has changed:


That means that the file has definitely changed. Exactly how, I'm not sure. Probably Imgur doing something to resize it.

If you want to be positive that the picture that you're getting is the picture that someone else is also looking at, you must have a checksum to verify that none of the bits got mucked up in transit. For the most part, the Internet does that (TCP/IP tells how to make sure that when you send information it all gets to the place that it's supposed to go, and if it doesn't get there then it has to complain loudly. Most of the Internet uses TCP/IP because of that) for you. However, as others have mentioned, there are a myriad of ways that quality of the image can change.

If you download Unikitty 4 and get the same SHA-256 sum that I did, you can know with almost complete certainty that the picture that you're looking at and the picture that I'm looking at are 100% identical.

Though then you have to worry if our monitors are color-calibrated the same, and if the ambient lighting is affecting anything, or...

  • 2
    \$\begingroup\$ I'm pretty sure imgur strips metadata. They might also recompress at upload. While they could alter data transmission based on bandwidth, this doesn't demonstrate that. Checksums do not have to match to have identical images. For instance, PNG is lossless with multiple compression levels. \$\endgroup\$
    – xiota
    Commented Jun 13, 2019 at 19:44
  • \$\begingroup\$ wget https://i.sstatic.net/t69qT.jpg ; sha256sum t69qT.jpg ; 3b5991bfaeff83bd6c1fef585f2fdee80cf649f84978d249b08c2b17a03702c2 t69qT.jpg \$\endgroup\$
    – xiota
    Commented Jun 13, 2019 at 19:46
  • 1
    \$\begingroup\$ Good point! A checksum can only be used as a guarantee that the images are the same, not that they are different. Heck, it's hard for me to tell whether 1 and 2 are different at all and they have completely different checksums. \$\endgroup\$ Commented Jun 13, 2019 at 20:52

It is possible that you are viewing the images as they are being downloaded (photos stored on cloud app like Google Photos) or it is fully downloaded but the software you are using to view the image hasn't completed rendering - so you are seeing an image in progressive rendering mode.

To answer your question, No the quality (i presume you meant the speed) of the network doesn't affect the quality of an image.


No. Digital files, contrary to their analog counterparts, are always perfect copies, so the image either fails to download, or is downloaded perfectly, every single time. Same thing applies to transfering them between mediums (SD to disk, pendrive, CD, ...) or creating copies.

Corrupt copies are possible, albeit very improbable, on some cases, but they are not "lower quality", but completely wrong (ie: only half the image and such).

  • 3
    \$\begingroup\$ Corrupt files are not "very improbable", but rather they are not uncommon. They can go unnoticed if files are not verified. \$\endgroup\$
    – osullic
    Commented Jun 11, 2019 at 9:55

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