How to Hide Filenames in a 7Z Archive (Header Encryption Explained)

This distinction matters more than a lot of people realize, because it's easy to compress a sensitive folder, add a strong password, and walk away feeling fully protected — without ever checking whether the archive's file listing itself is quietly still visible to anyone who opens it.

Most people assume that password-protecting an archive hides everything inside it — including the names of the files themselves. For standard ZIP encryption, and even basic 7Z encryption without an extra setting enabled, that assumption is wrong — and depending on what you're protecting, it can matter a lot more than people realize.

The gap in standard archive encryption

When you password-protect a typical ZIP or 7Z archive using default settings, the encryption applies to the contents of each file — but the archive's internal file listing (names, folder structure, individual file sizes) often remains fully visible without needing the password at all. Anyone who opens the archive in a file browser, or even just inspects it with a basic archive tool, can see "Tax_Return_2025.pdf," "Passport_Scan.jpg," or "Layoff_List_Q1.xlsx" sitting right there in the listing — they simply can't open the file's contents without the password.

Depending on the context, the filenames alone can leak meaningful sensitive information even while the actual contents stay locked down — sometimes the filename itself is the sensitive part, regardless of what's inside.

What header encryption actually does

The 7Z format supports an additional, separate option called header encryption (often labeled "encrypt filenames" or "hide filenames" in app interfaces, since "header encryption" is a more technical term most users wouldn't recognize). When enabled, it encrypts the archive's header — the section containing the file listing, folder structure, and metadata — along with the file contents that were already being encrypted. The result: someone without the password sees nothing but an opaque, unreadable archive. No filenames, no folder structure, no file count, no individual file sizes — nothing useful at all without the correct password.

This is a 7Z-specific capability. Standard ZIP encryption has no equivalent option, and RAR's header encryption support depends on the specific RAR version and the software used to create it — it's far less consistently available than in 7Z.

A realistic scenario: a freelancer sharing client contracts

Picture a freelance consultant storing signed client contracts in a shared cloud folder used by a small team, with each contract individually password-protected as a standard ZIP for basic access control. Without header encryption, anyone with folder access can browse the file listing and see client names directly in the filenames — Acme_Corp_Contract.zip, Smith_Retainer_Agreement.zip — revealing the full client roster to anyone who simply looks at the folder, even though the contract contents themselves stay locked. Enabling header encryption on these same archives would replace that revealing filename list with generic, opaque entries, meaning only someone with the correct password for a specific contract could confirm which client it even belongs to, let alone read its contents.

When this actually matters in practice

• Sharing sensitive documents where even the filenames reveal something meaningful on their own — legal documents, medical records, financial statements, HR materials.
• Storing backups on shared or cloud storage where other people with access to that storage location might browse the archive's listing without ever needing or attempting to open the actual contents.
• Journalism, whistleblowing, or other high-sensitivity contexts where metadata itself — who's named, what topics are referenced — can be as operationally risky as the content, sometimes more so.
• Personal archives stored on a shared family computer or NAS where you want genuine privacy from other users of the same device, not just from the public internet.

For everyday file sharing between two trusted parties — sending a password-protected ZIP to a colleague who already knows roughly what's in it — standard password protection without header encryption is usually perfectly fine. It's specifically the scenario where someone other than your intended recipient might end up browsing the archive listing without your permission that header encryption is designed to protect against.

How to enable it

This is exclusively a 7Z feature — if you need it, you have to use 7Z format rather than ZIP or RAR, since neither reliably supports it. In Unzipr, when compressing to 7Z format with a password set, a "Hide Filenames (Header Encryption)" toggle appears directly in the compression dialog. Enable it before compressing, and the resulting archive shows nothing but encrypted noise to anyone without the password — filenames included, not just file contents.

Header encryption versus full-disk encryption: not the same protection

It's worth distinguishing header encryption from other, broader forms of protection people sometimes conflate it with. FileVault, macOS's built-in full-disk encryption, protects everything on your drive while the Mac is powered off or locked — but once you're logged in, files are fully accessible, including any archive's file listing, regardless of whether header encryption is enabled on that specific archive. Header encryption operates at a different layer entirely: it protects a specific archive's contents and metadata independent of whether the underlying disk itself is encrypted, meaning the two are complementary rather than redundant. A header-encrypted 7Z archive on an unencrypted drive still hides its filenames from anyone who gains access to that file without the password; FileVault alone would do nothing to protect that same archive's filenames from someone who's already logged into an unlocked Mac.

What an attacker actually sees without header encryption

To make the risk concrete: imagine a standard password-protected ZIP or basic 7Z archive (without header encryption) sitting in a shared Dropbox folder, containing merger negotiation documents ahead of a public announcement. Anyone with folder access — even without the archive password — can see filenames like "Acquisition_Terms_Draft_v3.docx" or "TargetCo_Valuation.xlsx" in the file listing, immediately learning that a specific acquisition is in progress and roughly what stage it's at, without ever cracking the actual password-protected contents. This is precisely the scenario header encryption is built to close — the metadata leak happens entirely independent of whether the password itself ever gets compromised.

Troubleshooting

• Header-encrypted 7Z file shows zero files when previewed: this is expected behavior, not a bug — without the password, there is genuinely nothing to show, since the listing itself is encrypted.
• Recipient's extraction tool fails to even recognize the file as a 7Z archive: some older or more basic 7Z readers don't correctly handle header-encrypted archives and may misidentify the file type entirely — make sure your recipient has a reasonably current 7Z-compatible tool.

Frequently asked questions

Does header encryption make the archive slower to create or open? The difference is negligible — header encryption only affects the small metadata section, not the bulk of the compressed data, so there's no meaningful performance impact.

Can I add header encryption to a 7Z archive after it's already created? No — it has to be set at the time of compression. You'd need to extract the existing archive and recompress it with the option enabled.

If I forget the password, does header encryption make recovery even harder? Not meaningfully harder than standard encryption — both rely on the same AES-256 strength. Header encryption changes what's hidden (the listing as well as the contents), not how resistant the password itself is to recovery attempts.

How this compares to ZIP and RAR's actual encryption gaps

It's worth being precise about why ZIP specifically has no equivalent option, rather than just lacking it by oversight. ZIP's file format specification separates the central directory (the file listing) from the compressed data streams in a way that most implementations don't extend encryption to cover — even ZIP variants using strong AES-256 for file contents typically leave the central directory listing in plaintext, since encrypting it would break compatibility with the wide range of ZIP readers that expect to read that listing without a password prompt. RAR's situation is different again: RAR5 does support an option to encrypt filenames alongside contents, but it depends entirely on whether the specific software used to create the archive exposes that option and whether the recipient's extractor correctly supports RAR5's encrypted-header mode — support is real but considerably less consistent and less universally implemented than 7Z's version of the same idea, which has been a stable, well-supported part of the format for years.

A simple way to decide if you need it

Ask yourself one question before compressing: if someone other than the intended recipient saw only the list of filenames in this archive — no contents, just the names — would that alone tell them something you'd rather they didn't know? If yes, enable header encryption. If the filenames are as harmless as the contents are sensitive (a generically named backup, for instance), standard password protection is sufficient and header encryption is an extra step without much added benefit. When in doubt, enabling it costs essentially nothing in performance or compatibility with modern tools, so defaulting to it for anything genuinely sensitive is a reasonable habit rather than something to evaluate case by case every single time you compress a new archive.