TAR to ZIP on Mac and Windows: What Happens to Permissions

Someone on the Linux side of the project sends you build-assets.tar (430 MB). You double-click it on your Mac, Archive Utility unpacks it fine, and you forward it to two Windows colleagues. Ten minutes later: "Windows says it can't open this folder."

That's the whole problem in one sentence. TAR is a native citizen on macOS and Linux; on Windows it's a second-class format that needs 7-Zip, WinRAR, or a tar command most people don't know exists. ZIP opens everywhere with a double-click. Converting tar to zip takes about thirty seconds — but it quietly changes what's inside the archive, and if the payload is a set of shell scripts or a deployable build, that matters.

Below: the two routes (Terminal and browser), with real commands, and a straight answer on permissions and symlinks.

Why TAR breaks on Windows (and ZIP doesn't)

TAR isn't a compression format at all — it's a tape archive, a single stream that concatenates files plus their Unix metadata. Compression is bolted on afterwards, which is why you see .tar.gz, .tar.bz2 and .tar.xz. A plain .tar is uncompressed and often larger than the folder it came from.

ZIP is the opposite: each file is compressed individually and indexed in a central directory at the end of the archive. That design is why ZIP is baked into Windows Explorer, macOS Finder, Gmail previews, Slack, and every file manager on earth. For tar file mac compatibility you're fine either way. For sending to Windows, ZIP removes the support ticket.

Practical rule: if the recipient is going to look at the files, send ZIP. If the recipient is going to run the files on Linux, keep the TAR.

What gets lost in the conversion

This is the part most guides skip. TAR stores a full Unix metadata block per entry. ZIP stores a DOS-era attribute byte, with Unix modes tucked into an optional "external attributes" field that many tools write and many tools ignore.

Here's the honest breakdown of zip format unix permissions and friends:

• Executable bit (`chmod +x`) — stored by macOS/Linux zip, but dropped when Windows Explorer or many online tools rebuild the archive. Your deploy.sh arrives as a plain file.
• Owner and group (`root:staff`, UID/GID) — not preserved in any meaningful way. ZIP has no concept of ownership.
• Symlinks — zip can store them as links with the -y flag; without it, the link is followed and the target file is copied in, inflating your archive. Windows almost always extracts them as plain files.
• Hard links — not represented. Each becomes a full duplicate copy.
• Empty directories — preserved by both, usually fine.
• Modification timestamps — preserved, though ZIP's classic format rounds to 2-second precision.
• Extended attributes and ACLs — gone. On macOS you may also pick up __MACOSX/ and .DS_Store junk on the way out.

So convert tar to zip without permissions loss isn't fully achievable as a guarantee. If execute bits are load-bearing — a build artifact, a set of CLI tools, anything deployed by script — don't convert. Instead, ship the original .tar (or .tar.gz) and tell your Windows colleague to run tar -xf build-assets.tar in PowerShell, which has shipped with a working tar since Windows 10 build 17063.

Route 1: Convert TAR to ZIP on Mac with Terminal

There's no one-liner that transcodes a TAR into a ZIP directly. You extract, then re-archive. Three commands, with a real example:

# 1. Make a clean working folder and unpack into it
mkdir staging && tar -xf build-assets.tar -C staging

# 2. Check what you actually got (watch for symlinks, marked 'l')
ls -la staging

# 3. Zip it, preserving symlinks and skipping macOS junk
cd staging
zip -ry9 ../build-assets.zip . -x "*.DS_Store" "__MACOSX/*"

Flag by flag: -r recurses into subfolders, -y stores symlinks as links instead of copying their targets, -9 is maximum compression (slower, smallest file), and -x excludes patterns. Swap -9 for -1 if you're zipping tens of gigabytes and care more about speed than a few percent.

For a .tar.gz, step 1 becomes tar -xzf build-assets.tar.gz -C staging. For .tar.bz2 use -xjf; for .tar.xz, -xJf. Modern macOS tar auto-detects, so plain -xf usually works regardless.

Expect the size to change. An uncompressed 430 MB .tar of text-heavy source might land at 90–120 MB as a ZIP. A TAR full of JPEGs and MP4s will barely shrink at all — those bytes are already compressed.

Quick sanity check before you send it:

unzip -l ../build-assets.zip | tail -5

Route 2: Convert the TAR file on Mac online, no Terminal

If you're not a command-line person, or you're on a locked-down work Mac without Homebrew and don't fancy installing Keka just for one file, do it in the browser. Drop the archive into the TAR to ZIP converter, wait for it to repack, and download the .zip.

Three things to know before you upload:

• It's the right call for documents, images, design files, exports and reports — content where only the bytes matter.
• It's the wrong call for executables, build outputs or anything with symlinks. Treat execute bits as lost, as with most repack-based tools.
• Don't upload anything confidential. Client contracts, credentials, customer data: use Terminal instead. That's a general rule for any online converter, not a comment on one service.

Working with .tar.gz, .7z or .rar too? The archive converter hub covers the other combinations in the same way.

Choosing between the two routes

• Confidential contents? → Terminal. No upload, no third party.
• Execute bits or symlinks matter? → Don't convert. Send the .tar and the tar -xf command.
• Archive over ~1 GB? → Terminal. Faster than uploading and re-downloading.
• Just a folder of files for a colleague? → Online converter. Done in a minute.
• Need it to stay small too? → Terminal with -9, or send a .tar.gz if the recipient can handle it.

Sending it off without the follow-up email

Two habits save you a round trip. First, name the file for a human, not a pipeline: build-assets-2024-06.zip beats archive_final_v2.zip. Second, if the ZIP contains anything runnable, say so in the message — "scripts in /bin need chmod +x after extracting" is one line that prevents a confused reply.

And if the recipient turns out to be comfortable in a terminal after all, the simplest convert tar to zip for windows answer is to skip the conversion entirely: Windows 10 and 11 unpack TAR natively from PowerShell. Convert when it buys convenience, not out of habit.

FAQ

Can macOS open a .tar file without any extra software? Yes. Double-click it and Archive Utility extracts it, the same as a ZIP. The problem is only on the Windows side.

Will the ZIP be smaller than the TAR? Usually, because a plain .tar is uncompressed. But a .tar.gz is already compressed, so the resulting ZIP is often slightly larger.

Does Finder's "Compress" keep permissions? Right-click → Compress uses the same underlying machinery as zip and does record Unix modes — but it also sprinkles in __MACOSX folders and .DS_Store files that look like clutter to Windows users. The -x flags above avoid that.

Why is my ZIP huge after converting a TAR with symlinks? You zipped without -y, so every symlink was replaced by a full copy of its target. Re-run with zip -ry9.

How do I restore the executable bit after extracting on Mac or Linux? chmod +x script.sh for one file, or find . -name "*.sh" -exec chmod +x {} + for a whole tree.

Is .tar.gz or .zip better for backups? .tar.gz for Unix systems — it keeps ownership, modes and symlinks intact. .zip only when cross-platform access beats fidelity.