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

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.

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.

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.

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.