Password-protecting a file is not the same as encrypting it

"Password-protected" and "encrypted" get used as if they were the same claim. Sometimes they describe the same thing. Often one of them is a door with a lock painted on it.

Knowing which you have matters, because the weak versions are common and they look identical from the outside.

Three different things

1. A password that gates access

A service checks a password before it shows you the file. The file itself is stored normally; the password is a rule the server enforces.

This protects against someone who has the link but not the password. It does nothing against anyone who can reach the stored file directly — the provider, an employee, or anyone who finds a misconfigured bucket. There is nothing cryptographic happening to your data.

2. A password that hides content without encrypting it

The weakest version, and it is still everywhere. Certain document "protections" only ask the application to behave: a PDF flagged as restricted for editing or printing, or a spreadsheet with sheet protection turned on. The content is sitting in the file in plain form, and any tool that ignores the flag reads it. These are politeness, not security.

3. A password that derives a key and actually encrypts

The real thing. Your password is stretched into a cryptographic key, and the content is transformed with it. Without the password there is nothing to read — not a locked version of the data, just noise.

A zip made with AES-256, a PDF with proper encryption, or a transfer sealed in your browser before it uploads are all in this category.

How to tell which one you are using

• Can the provider preview it? A thumbnail or a text preview means the server read the contents.
• Can the password be recovered or reset? If support can restore access, the data was never encrypted with something only you held.
• Can the file be renamed or the flag removed? If stripping a setting reveals the content, it was never encrypted.
• Is the password required to open, or only to edit? Edit restrictions are almost always the cosmetic kind.

Zip encryption: two very different formats

Worth knowing because both are called "password-protected zip".

ZipCrypto is the legacy scheme, still the default in some tools. It is broken, and has been for decades — a known-plaintext attack recovers the contents quickly. Treat it as no protection at all.

AES-256 zip encryption is genuinely strong. Most modern archivers offer it, usually as a checkbox or an "encryption method" dropdown, and it is worth going to find.

Both have the same leak regardless of strength: the file names inside the archive are visible without the password in the standard zip format. A list of filenames often gives away most of what the encryption was protecting.

The mistake that undoes all of it

Sending the password in the same message as the file.

It is extremely common, and it reduces even AES-256 to decoration. Anyone who can read the email has both halves. The whole value of a password is that it travels by a different route than the thing it unlocks: the file by email, the password by phone, or a message on a different service.

If both halves arrive in the same place, you have not protected the file. You have added a step.

Where a passphrase is strong, and where it is not

Any password-derived key is only as good as the password, which is why key stretching matters. Running the password through hundreds of thousands of hashing rounds makes each guess expensive, turning a fast offline attack into a slow one.

Here, a typed secret goes through PBKDF2 at 250,000 rounds against a per-transfer random salt. That buys a great deal of time against a weak passphrase; it does not make password1 safe. Four random words beat one clever substitution every time.

The alternative is not typing one at all: a generated secret — four groups of four characters, from an alphabet with no 0/O or 1/l/I so it survives being read down a phone — has real randomness behind it rather than whatever you thought of at the time.

What to actually do

• For a file going through a service, prefer end-to-end encryption over a password gate. The provider holding bytes it cannot read is a stronger property than the provider agreeing to ask for a password.
• If you use an encrypted zip, pick AES-256, and remember the filenames are still visible.
• Send the secret separately, always.
• Do not rely on PDF or spreadsheet "protection" for anything confidential.
• Prefer a generated secret to an invented one.

Related: what end-to-end encryption actually means and how to send files securely.