Convert 7Z to TAR

This is a tooling conversion. Something downstream reads tar — a container build context, a packaging script, an import endpoint, a piece of infrastructure written against `tar -x` and still running — and the archive you were handed is a 7Z because whoever made it cared about size.

The tarball is therefore an intermediate rather than a thing you keep. Judge it by whether the next step accepted it, not by its size, and expect to delete it once that step has run. That framing matters because by every other measure this conversion makes the file worse: bigger, no faster to move, and no easier for a person to open. It is the right output only when something specific is waiting for it, which is why the page spends more time on what to expect than on why to want it.

7Z is solid and uses LZMA2 with a dictionary our registry records at up to 64 MB: members are compressed as one continuous stream and repetition anywhere within tens of megabytes is stored once. TAR's compression, in the same registry, is recorded as none.

So the whole of that work is undone and nothing at all replaces it. A 7Z of a source tree or a document set can expand many times over, which makes this the largest output of any conversion in the archive family and the one most likely to surprise somebody watching a download bar. It is not a defect: the two formats answer different questions, and only one of them is about size. Plan for the result rather than the source when you decide where to put it, because the 25 MB you are allowed to upload can comfortably become a download several times that.

Archives sometimes contain other archives, and a converter has to decide whether that inner file is packaging or content. The rule here is explicit: for GZ, BZ2 and XZ sources, a single tar that falls out is a layer and gets unwrapped, because those formats hold one stream and a tar underneath is the only way they carry a directory.

For a 7Z or a ZIP the opposite holds. Both are real containers that can hold many files with names, so a `.tar` inside one is something the author put there on purpose — a nested archive, a fixture, a payload for something else. Unwrapping it would silently change what the archive contains, so it comes through as a file and you get a tar containing a tar. That is the correct answer even though it looks odd.

Because 7Z is solid, there is no cheap way to read part of it. The members are one stream, so reaching a file in the middle means decompressing everything before it — which is why extracting a large solid archive costs about the same whether you want one file or all of them.

For this conversion that costs nothing, since every member is needed anyway. It is worth knowing for the reverse case: if you are picking through an archive repeatedly rather than unpacking it once, a solid format is the wrong storage choice, and a tarball is oddly not much better — it has no index at all, so listing it means reading it from the beginning. ZIP is the format that actually solves that problem, which is a good reason not to treat these three as interchangeable.

TAR records a file mode, a user and a group for every member, and that capability is exactly why packaging tools want tarballs. What it cannot do is recover values that were never carried through. The modes in your output come from the extraction on our converter, not from the machine where the files were created.

Treat them as unspecified rather than preserved, and set what matters after extracting — the executable bit on a script is the usual thing that breaks, and it breaks in a way that looks like a problem with the script rather than with the archive. The site-wide rule for these pairs is the same: members come out byte for byte, container knowledge is what is at risk.

A frequent reason to want a plain tarball is that you intend to compress it again with flags of your own — a specific level, a specific dictionary, a deterministic setting for a reproducible build, or a compressor that a downstream cache understands.

Taking the 7Z apart is the honest way to get there, because you cannot re-encode a compressed stream into a different compressor without decompressing it first. If your requirements are ordinary rather than particular, converting the 7Z straight to GZ does the same round trip in one step and hands you a `.tar.gz` at the end of it.

This pair runs on our converter and not in the page. The archive is uploaded over an encrypted connection, extracted with 7-Zip, written back out as a tarball from inside the extracted directory, and returned. The upload and every intermediate are deleted when the job ends, on a memory-backed working directory that is discarded with the container.

The limits worth planning around: 25 MB per upload on the free tier, sixty seconds before a job is killed, and a refusal for any archive declaring more than 2 GB of unpacked content. The upload limit applies to what you send, so a compact 7Z can produce a download several times larger than the file that started it.

Two refusals are worth knowing. An encrypted 7Z stops immediately, because the extractor is deliberately run with an empty password so it fails rather than blocking on a prompt that cannot be answered. And an archive that turns out to hold nothing gets a plain message rather than a valid but empty tarball.

The expansion guard is the third. Before anything is written to disk the archive is asked what it claims to contain, and a total above 2 GB is refused — a defence against files built to fill a filesystem rather than to hold data, and occasionally an honest archive that is simply too big for a web service.

If the tarball is going to travel — uploaded, fetched, copied between machines, cached by something — the uncompressed form is the wrong thing to move, and it is the form most likely to make a slow link look broken. Every single-stream target on this site is produced by tarring the contents and then compressing them, so converting the 7Z to GZ hands you the same tarball with gzip wrapped around it in one operation and one download.

Ask for TAR when a tool wants a bare tarball and will compress it, or not, on its own terms. Ask for GZ when the file crosses a network or lands in a package cache. The two look nearly identical in a file listing and behave very differently in a pipeline, and choosing wrongly usually surfaces as a transfer that takes an order of magnitude longer than anybody budgeted for, several steps away from the decision that caused it.

Packaging work often needs the same input to produce the same bytes every time, and a tarball is one of the places that quietly fails. Member order, timestamps and the modes written into each header all come from the extraction that produced them, so two conversions of the same 7Z can differ from one another while both faithfully containing the same files.

If a build compares checksums of the tarball itself rather than of its contents, that difference will be reported as a change when nothing meaningful changed. The fix is not a different converter but a different place to do the work: reproducible archives need a pinned local toolchain where sort order and timestamps are set explicitly, which is exactly what packaging tools provide and what a web service cannot. Use this page to get the contents out of the 7Z, and let your own tooling write the tarball that has to be reproducible.