Convert Any File to TGZ Online (Bundling Into Tar, Then Compressing With Gzip)

Two Separate Jobs Happening Behind One Extension

Producing a TGZ file from one or more input files is really two distinct operations performed back to back, even though the result carries a single three-letter extension. First, tar — the Unix archiving format from Seventh Edition Unix in 1979 — writes each input file into the archive as a 512-byte header record followed by that file's raw data, padded out to the next 512-byte boundary. Tar's own job stops there; it has no compression logic built in at all, and a plain .tar file holding a single small text document is typically larger than the original file, not smaller, because of that header and padding overhead.

Second, gzip takes whatever tar produced — a single continuous stream — and compresses it as one pass, with no awareness that the data inside represents multiple separate files at all. From gzip's point of view, a TGZ conversion of ten files and a TGZ conversion of one giant file that happens to be the same total size look identical: gzip only ever sees bytes, never file boundaries, since tar has already flattened everything into one stream by the time gzip gets involved.

A single input file goes through the exact same two steps as a whole folder of files, even though it might seem unnecessary to wrap one file in a tar structure before compressing it. Skipping the tar step and compressing a single file with gzip alone would produce a plain .gz file instead, which holds exactly one file with no wrapper structure at all; producing a TGZ instead of a plain .gz is a deliberate choice made specifically when Unix metadata like ownership and permission bits needs to be preserved, or when the file might later be joined by others inside the same archive.

What DEFLATE Does Once It Receives Tar's Combined Stream

Gzip's compression algorithm, DEFLATE, was later formally specified in RFC 1951, and it works in two layered steps of its own: LZ77 back-referencing, which replaces a repeated sequence of bytes with a short reference back to where an identical sequence appeared earlier within a 32 KB sliding window, followed by Huffman coding, which assigns shorter binary codes to whichever byte values occur most frequently in what's left after the LZ77 pass. Every gzip stream, including the one wrapped around a TGZ's tar data, starts with the fixed magic bytes 0x1F 0x8B, which is how any gzip-aware tool immediately recognizes the format regardless of what filename extension is attached.

Because tar concatenates every input file into one stream before gzip ever runs, DEFLATE's 32 KB window can pick up on repetition between different files, provided they're close enough together in that combined stream — which is exactly the "solid compression" behavior that a format like ZIP, compressing each file independently instead, deliberately doesn't offer. Bundling many small, textually similar files — configuration files, source code, log exports — into one TGZ specifically benefits from this, since redundant content across files gets exploited rather than ignored.

This also means the order files are added to the tar archive can have a small but real effect on the final compressed size: two similar files placed next to each other in the stream have a better chance of falling within DEFLATE's 32 KB window of each other than the same two files separated by several large, unrelated files in between.

This is also why a TGZ built from files that are individually already compressed — photos, videos, or already-zipped data — rarely shrinks much further. DEFLATE's LZ77 stage looks for repeated byte sequences, and well-compressed data has, by definition, already had most of its redundancy squeezed out, leaving gzip very little left to work with regardless of how the tar stream orders the files.

What Building a New TGZ From Scratch Gains and Costs

• Gain — Unix permission bits and ownership preserved in the tar layer: file mode, owner, and group get recorded directly in each 512-byte tar header, which matters for backups and system migrations.
• Gain — fast compression compared to bzip2 or xz: DEFLATE processes data quickly in both directions, which is a large part of why gzip stayed the default for build tooling for decades.
• Lose — the tightest possible compression ratio: bzip2's block-based approach and xz's LZMA2 algorithm both generally compress source-code-style and text-heavy content tighter than gzip's fixed 32 KB window can.
• Lose — random access to any single bundled file: extracting one file from a TGZ requires decompressing the gzip stream from the beginning, since there's no per-file index the way ZIP's central directory provides.
• Gain — near-universal read support once created: essentially every current operating system and archive tool can decompress a TGZ, even if not every one of them can create one by default.

Where Creating This Format Works Without Any Extra Software Installed

Apple's own documented list of formats Archive Utility handles natively on macOS includes .tgz directly, and macOS's Terminal ships GNU tar (or a BSD-tar-compatible equivalent) with gzip support built in, so producing a TGZ from the command line or through Archive Utility's own compression options requires no separate installation there. Linux distributions universally ship tar and gzip as part of their base system, and GNU tar's -a / --auto-compress flag detects the .tgz suffix on the destination filename and picks gzip automatically without needing to specify the compression method separately.

Windows has no built-in graphical way to create a TGZ through File Explorer, but Windows 10 version 1803 and later ships a command-line tar.exe based on the libarchive project, which can create gzip-compressed tar archives directly from a terminal. For a graphical option, 7-Zip and WinRAR both support building a .tar.gz or .tgz archive as an explicit output choice in their compression dialogs.

The Real Reasons Someone Needs to Produce a New TGZ File

A very common, documented pattern involves preparing source code or build output for distribution on Linux or Unix-like systems, where .tar.gz or its shortened .tgz form is the expected default for release archives across a huge share of open-source projects — using anything else risks confusing users who specifically expect this convention when they download a release.

A second real scenario involves backing up a directory tree that needs Unix ownership and permission information preserved exactly, something that matters for restoring a server configuration or a multi-user filesystem correctly — TGZ carries that metadata directly in its tar headers, where a permission-agnostic format wouldn't. A third pattern shows up in package management specifically: Slackware's own installer expects .tgz or .txz packages by convention, and building a compatible package for that ecosystem means producing exactly this format rather than any generic archive type.

A fourth pattern involves continuous integration pipelines that publish build artifacts for Linux-based deployment targets, where downstream deployment scripts already expect to run a specific decompression command against a .tar.gz or .tgz file as a fixed step in an existing automation chain — producing that exact format keeps the rest of the pipeline unchanged rather than requiring every downstream script to be rewritten around a different archive type.

Building a TGZ Set Against Building a ZIP From the Same Files

Questions About Turning Files Into a New TGZ Archive

Is a TGZ file the same thing as a TAR.GZ file?
Yes, completely. TGZ is simply a shortened spelling of the exact same tar-plus-gzip format, created to fit old 8.3 DOS filename rules and short Unix filename limits, and the resulting bytes are identical either way.

Will bundling several files into one TGZ shrink them more than compressing each one separately?
Often, yes, for similar files, since gzip compresses the entire combined tar stream as one solid pass and can exploit repetition between files, something separately compressing each file on its own can't do.

Do I need special software on Windows to create a TGZ?
File Explorer has no built-in option, so 7-Zip, WinRAR, or the tar.exe command-line tool included since Windows 10 version 1803 is needed.

Does converting my files to TGZ lose any file permissions or ownership?
No, that information is preserved directly, since tar's own header format records file mode, owner, and group for every entry before gzip ever compresses the resulting stream.

Why doesn't my TGZ get much smaller when it's full of photos or videos?
Those file types are typically already compressed internally, so gzip's DEFLATE stage finds very little repeated data left to exploit, regardless of how many files are bundled together in the tar stream underneath.