ZIP is the archive format every operating system opens without help. TAR is an uncompressed bundle of files, the Unix way. Python sits between the two, and this page says exactly what happens to a ZIP file on the way to becoming a TAR one.
What runs when a ZIP file becomes TAR
Python and its standard library, on a machine we rent and watch. Your ZIP file is uploaded once, Python runs once, the TAR comes back, and neither file is kept. ZIP to TAR is one of the 3649 pairs that engine was probed on with a real file, which is why it has a page here and why the pairs the probe could not prove do not.
What survives from the ZIP into the TAR
Every file, byte for byte, with the path it had. This pair reads each member out of the ZIP and writes it into the TAR unchanged: nothing is recompressed twice, re-encoded or renamed. The engine counts the members on the way out and refuses the result if the count moved.
Directory structure. A file that lived in reports/2024/ arrives in reports/2024/, which is what makes the TAR openable rather than a heap.
Speed, and nothing else. A TAR compresses nothing, so this pair costs almost no time: measured on this engine, 200 MB pass in 3,3 seconds against 59 for 7z. It is the format you want when something else is going to compress it, or when the files are already compressed and squeezing them again would only waste minutes.
File metadata as the Unix world records it. TAR was written for tape in 1979 and it keeps what tape kept.
What ZIP to TAR costs you
Symbolic links, hard links and special files. They are dropped rather than copied, and the response says how many: a link means something only relative to the machine that wrote it, and carrying one into an archive bound for another machine is how you build a trap. If your ZIP holds links, the TAR will hold the files and not the links.
Unix permissions and ownership. The TAR is written with a fixed mode and a zero timestamp, deliberately: the same input then always produces the same bytes, and the rights of a machine you do not control mean nothing on yours.
Compression entirely, which is the point and still a surprise. A TAR lays the files end to end and squeezes nothing: expect it to be as large as its contents, sometimes larger than the ZIP you started from.
Where ZIP and TAR files come from
ZIP. Phil Katz published it in 1989 and it never went away. Its one decisive property is that each file inside is compressed separately, which is why a ZIP opens instantly and why it compresses worse than the others: nothing is shared between two files that look alike.
TAR. Tape ARchive, from 1979, and it does exactly what the name says: it lays files end to end with their metadata and compresses nothing. That is why it is almost always paired with a compressor, and why a bare .tar is usually larger than the files it holds.
If a model is going to read the TAR
Structure is what survives from the ZIP file, and structure is what a model needs. ZIP in, TAR out, with the heading tree intact instead of flattened into one long paragraph.
ZIP to TAR, measured rather than promised
Running ZIP to TAR against the real engine with a real file, Python wrote 10,240 bytes of TAR in under a tenth of a second, machine otherwise idle. That is one ZIP file on one day and not an average, which is why the number is given together with the file that produced it.
The ZIP to TAR verdict was reached by reading the archive members back and finding a witness word, meaning the output was read back and recognised. Which check was used matters, because they do not all prove the same thing, and a status code of 200 proves nothing whatsoever about whether the TAR file has anything inside it.
Other ways into TAR, and what they measured
Among the published routes into TAR, ZIP is the third largest output of the 3 measured. The witness files differ, so this ranks the probe run and not your document.
TGZ to TAR: 10,240 bytes in under a tenth of a second.
7Z to TAR: 10,240 bytes in under a tenth of a second.
What we will not pretend about ZIP to TAR
A ZIP file over 100 MB is refused before the upload finishes rather than after it, so you do not wait for a rejection.
A ZIP to TAR run that passes 110 seconds is killed, and the Python process is killed with it. A run left behind would sit on one of the machine's two cores until somebody noticed.
An archive is the only kind of file whose contents decide how much room they will need once opened, and two kilobytes can hold ten gigabytes of zeros. This is a decompression bomb, it is thirty years old and it still works. Three limits answer it here, and they COUNT rather than trust the header, which can lie: 100 MB uploaded, 250 MB once decompressed, 5000 entries. A ZIP past any of them is refused, and the refusal names which one.
Nothing is written to disk on our side, not even temporarily. An archive is also the only kind of file whose contents decide FILE NAMES, and an entry called ../../etc/passwd is an attack as old as the format. Members pass from ZIP to TAR in memory, so there is no destination directory to escape from. The names are cleaned anyway before they enter the TAR: that part protects whoever opens it, not us.
One ZIP file at a time, chosen in the browser. There is nothing else to set up and nothing else on offer.
ZIP to TAR: what people ask
What actually converts my ZIP file to TAR?
Python does it, and its standard library, on a machine we rent and watch. Not a browser trick and not somebody else service: the ZIP file is uploaded once, Python runs once, the TAR comes back, and neither file is kept afterwards.
How long does ZIP to TAR take?
On the file the probe used, Python took under a tenth of a second and wrote 10,240 bytes of TAR. That is one real measurement on one real ZIP file, not an average and not a promise about yours: a larger ZIP takes longer, and past 110 seconds the run is stopped.
What do I lose going from ZIP to TAR?
The one to know about first: Symbolic links, hard links and special files. They are dropped rather than copied, and the response says how many: a link means something only relative to the machine that wrote it, and carrying one into an archive bound for another machine is how you build a trap. If your ZIP holds links, the TAR will hold the files and not the links.
Are my files changed in any way?
No. Each one is read out of the ZIP and written into the TAR byte for byte, with the path it had. What changes is the box around them. The engine counts the members on the way out and refuses the result if the count moved, which is the one way this could go wrong quietly.
Why would I want an uncompressed TAR?
Two reasons. Something else is going to compress it, and compressing twice wastes time for nothing. Or the files inside are already compressed, images or video, and squeezing them again gains almost nothing while costing minutes.
What happens to symbolic links?
They are dropped, and the response says how many. A link means something only relative to the machine that wrote it; carrying one into an archive bound for another machine is how you build a trap. The files stay, the links do not.
Is there a size limit?
Three, and they are stricter than for other formats for a reason: an archive decides how much room it needs once opened, and two kilobytes can hold ten gigabytes. 100 MB uploaded, 250 MB once decompressed, 5000 entries. Past any of them the answer says which one, rather than a generic refusal.
Is ZIP to TAR free?
There is a free allowance every month, and one ZIP to TAR conversion costs half a credit against it. When the allowance runs out the tool says so and stops, rather than quietly handing you a worse TAR.