File to TAR.GZ Converter

Making a TAR.GZ Online: What This Tutorial Covers

A .tar.gz is two things stacked: a tar archive that bundles several files into one stream, then gzip compression applied to that whole stream. It is the default way source code, server backups and Unix deployments are packaged, and it is what a tar -xzf command on any Linux or macOS machine expects. This page bundles the files you upload and hands back the tarball; below the steps you will find how to unpack it on each platform, what the archive genuinely preserves, and where the format is the wrong choice.

How to Convert File to TAR.GZ

1. Upload Your Files: Drag and drop them onto the page, or click "+ Add Files" to browse. There is no format restriction on what goes into an archive — documents, images, video, source code and binaries all bundle the same way.
2. Choose Single Archive or Individual Archives: Under Combine?, Single Archive is preselected and packs everything you uploaded into one .tar.gz. Switch to Individual Archives to wrap each file in its own separate tarball instead.
3. Add Anything Else You Want Inside (Optional): Upload the remaining files before converting — with Single Archive selected, everything in the queue goes into the same tarball, so it is worth getting the full set in place first.
4. Convert and Download: Click "Convert" and download the result. No sign-up, no watermark.

Walk-through: Single Archive vs Individual Archives

This is the only decision the page asks you to make, and the on-page note states it plainly: Single Archive combines all uploaded files into a single archive, while Individual Archives creates a separate archive for each individual file.

• Single Archive is the default and is what you want almost every time. Ten files go in, one .tar.gz comes out, named after the first file in the batch. This is the "here is the project" or "here is the backup" shape.
• Individual Archives produces one tarball per input — ten files in, ten .tar.gz files out, delivered together as a ZIP for convenience. It is useful when the files will be distributed separately, or when a receiving system ingests one archive at a time.
• Compression is fixed. Unlike some desktop tools, there is no compression-level slider here; gzip runs at its normal setting. If you need a meaningfully smaller archive, changing the algorithm to xz via File to TAR.XZ does far more than tuning gzip would.

TAR.GZ Compared With the Alternatives

How to Extract a .tar.gz

Common Errors and How to Fix Them

• "Windows made it a .tar.gz.tar or opened it as one file." Some Windows tools unwrap only the gzip layer and leave the .tar behind. That is normal — open the .tar too.
• "The archive is barely smaller than the files I put in." gzip cannot compress data that is already compressed. A tarball of JPEGs, MP4s or PDFs will be close to the sum of its inputs. That is expected, not a failure; use .tar if you only wanted the bundling.
• "I expected my folder structure inside." The archive is built from the files you uploaded, as a flat list of names. Directory trees are not reconstructed, because a browser upload sends files, not folders.
• "My colleague on Windows can't open it." They can with 7-Zip or a current Windows tar command, but if you want zero friction, File to ZIP is the safer format to send to a Windows-only recipient.
• "The archive name isn't what I expected." With Single Archive, the output takes its name from the first file in the batch. Rename it after downloading.

When This Doesn't Work

Two situations fall outside what an online archiver can do. The first is anything that depends on filesystem metadata: a browser upload transmits a file's name and its bytes, not its Unix mode bits, ownership or symlink targets, so a tarball built here cannot carry the permissions your originals had. If you are packaging something where the executable bit or a symlink matters — a release tarball, a deployment bundle — build it with tar on the machine that owns the files. The second is very large inputs, where upload time dominates everything else; compressing locally first and uploading the result is faster than uploading raw material to be compressed. For the ordinary case — a handful of files that need to become one downloadable bundle — this page is the shorter path.

Frequently Asked Questions

Does this preserve Unix file permissions, ownership and symlinks?

No, and it is worth being precise about why. The tar format records permissions, ownership, paths and symlinks, which is exactly why source tarballs and server backups use it. But a browser upload only sends each file's name and its contents — mode bits, owner and group, and symlink targets never leave your machine, so they are not available to record. The archive you get back is a valid tarball whose entries carry whatever ordinary permissions the server's temporary files had. For a release bundle where the executable bit matters, run tar czf on the machine that owns the files.

Is making a TAR.GZ lossless — will my files change?

Yes, it is fully lossless. gzip is specified in RFC 1952 as a lossless compressed data format built on DEFLATE, and it includes a CRC so corruption is detectable rather than silent. Your files come back out of the archive byte for byte identical to what went in. Nothing about their content, quality or encoding is altered — the archive only bundles and compresses.

Why is it "tar" and "gz" — what does each layer actually do?

They are separate tools doing separate jobs, which is a genuinely different design from ZIP. tar ("tape archive") concatenates files into one continuous stream with a header before each entry; it does no compression at all. gzip then compresses that whole stream as a single unit. The upshot is that repetition between files gets compressed too, which is why a tarball of many similar small files is often noticeably smaller than the equivalent ZIP — ZIP compresses each entry independently. The trade is that pulling one file out means reading the stream up to it, rather than jumping straight there.

Can I choose a compression level?

Not on this page — gzip runs at its normal setting and there is no level control. In practice tuning gzip's level is a small lever anyway; the difference between its fastest and slowest settings on typical data is modest, and the slow end costs real time. If the archive is too big, the algorithm matters far more than the level: File to TAR.XZ uses LZMA2 and will usually beat any gzip setting by a wide margin, at the cost of slower compression.

What will the archive be named, and how are the files laid out inside it?

With Single Archive, the output is named after the first file in your batch, so a queue starting with report.pdf yields report.tar.gz. Rename it after downloading if you want something more descriptive. Inside, the entries are a flat list of the filenames you uploaded — there are no nested directories, because a browser upload sends individual files rather than a folder tree. Anyone extracting it gets your files dropped into the current directory, so it is polite to warn them, or to extract into a fresh folder yourself.

What is the difference between Single Archive and Individual Archives?

Single Archive, the default, packs every file you uploaded into one .tar.gz — the usual choice for bundling a project, a set of documents or a backup. Individual Archives wraps each uploaded file in its own separate .tar.gz, so five files produce five tarballs, handed to you together as a ZIP. Reach for the second only when the files genuinely travel separately afterwards; for anything you are going to send as one attachment or one download, Single Archive is what you want.

Should I use TAR.GZ, TAR.XZ, ZIP or 7z?

Use .tar.gz when the recipient is on Linux or macOS, or when you want the format that every Unix toolchain reads without installing anything. Use ZIP when a Windows recipient will double-click it, since Windows opens ZIP natively and treats tarballs as a two-step job. Use TAR.XZ when download size is the priority and slower compression is acceptable — LZMA2 beats gzip substantially on text and source code. Plain TAR is right only when the contents are already compressed and gzip would just add CPU time for nothing.

How are my files handled, and how long are they kept?

Your files are uploaded over an encrypted connection, archived on our servers, and deleted automatically after a few hours. There is no sign-up, no watermark, and they are never shared, made public, or used for anything beyond building your archive. Because compression happens after upload rather than before, the slow part of a large job is always the upload itself — if the material is already compressed and enormous, packaging it on your own machine will finish sooner.