The latest Chrome and Chromium seems to unpack .tar.gz files automatically for me on OS X and Linux. When using wget with the same URL, it shows:

$ wget http://mydomain/dir/file.tar.gz
HTTP request sent, awaiting response... 200 OK
Length: ... [application/octet-stream]

Verifying the file type:

$ file file.tar.gz
file.tar.gz: gzip compressed data, from FAT filesystem (MS-DOS, OS/2, NT)

When doing the same for the file downloaded with Chrome or Chromium:

$ file file.tar.gz
file.tar.gz: POSIX tar archive

Note, that Chrome/Chromium obviously kept the file name, but expanded it (the file size is ~4 times bigger than from the wget-downloaded file).

As website administrator how can I prevent Chrome/Chromium from unpacking the file?


According to curl -I http://mydomain/dir/file.tar.gz our Apache/Tomcat combo responds with

Content-Encoding: x-gzip

Tried .tar.gz files from other websites are not unpacked by chrome and don't report the Content-Encoding: x-gzip header, so there seems to be a relation.


Your web server is likely sending the .tar.gz file with a content-encoding: gzip header, causing the web browser to assume a gzip layer was applied only to save bandwidth, and what you really intended to send was the .tar archive. Chrome un-gzips it on the other side like it would with any other file (.html, .js, .css, etc.) that it receives gzipped (it dutifully doesn't modify the filename though).

To fix this, make sure your web server serves .tar.gz files without the content-encoding: gzip header.

More Info: https://code.google.com/p/chromium/issues/detail?id=83292

| improve this answer | |
  • I already have changed the Tomcat to send application/octet-stream for gz files (see the wget output). It did not change anything. Beside that, it seems to be a new feature of Chrome - can't remember it already had unpacked files 3 months ago. – Thomas S. Jul 20 '15 at 13:51
  • 2
    @ThomasS. As far as I know, your issue is due to sending the content-encoding: gzip header, it doesn't have to do with the application/octet-stream content type. In other words, I am advising you to change your content-encoding header, not your Content-Type header. – Maximillian Laumeister Jul 20 '15 at 17:05
  • The bug is marked fixed, but I just found the same issue in 2018 but with .tgz extension. Example URL: lysator.liu.se/~jc/wotsap/download/wotsap-0.7.tgz – Jonathan Cross Nov 26 '18 at 16:54

According to our hosting provider the header Content-Encoding: x-gzip was caused by the Apache in front of our Tomcat. Removing following line:

LoadModule deflate_module               modules/mod_deflate.so

from its configuration solved the problem.

| improve this answer | |
  • 3
    Disabling mod_deflate will disable HTTP compression for all files, which is probably not what you want; HTTP compression is important. A better option is to configure Apache to not alter .gz files, with something like RemoveOutputFilter. – MultiplyByZer0 May 27 '19 at 22:19
  • @MultiplyByZer0 Maybe you want to write a standalone answer to be accepted? – Thomas S. May 28 '19 at 8:11

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.