Converting password protected Excel files safely

Finance, HR and legal teams protect workbooks for good reasons. Payroll, salary bands, customer contracts and board figures should not be readable by anyone who finds the file. The trouble starts when that data has to move into another format, such as a CSV for an accounting import or a PDF for a report. Many converters cannot open an encrypted file at all, and others ask you to remove the password first, which leaves an unprotected copy on someone's desktop. This article explains what Excel protection actually does and how to convert protected files without weakening it.

Three kinds of Excel protection

Excel uses the word password for several features that work in very different ways.

Only the password to open protects the content. Sheet and workbook protection stop casual edits, but the data is stored in plain form inside the file, and any program that reads the file format can see it. Treat sheet protection as a guard rail for people, not as security for data.

How a password to open works

For XLSX, XLSM and XLSB files, Excel 2010 and later use what the ECMA-376 standard calls agile encryption. The normal workbook package is encrypted and wrapped inside a different container, so an encrypted XLSX is not a ZIP file at all from the outside.

In simplified terms, the process works like this.

1. A random salt is combined with your password and hashed with SHA-512, repeated 100,000 times by default. The repetition makes each password guess slow for an attacker.
2. The result unlocks a randomly generated key, which encrypts the workbook with AES, typically with a 256 bit key.
3. A stored password verifier lets the reader detect a wrong password, and an HMAC over the encrypted data detects a modified file.

The important consequence is that there is no shortcut. Without the password, the content cannot be read, apart from guessing the password. A strong password on a modern workbook is effective protection.

Older XLS files

Legacy XLS workbooks from Excel 97 to 2003 used RC4 encryption, which is much weaker by modern standards, and some very old files used an obfuscation scheme that offers almost no protection. If your archive contains sensitive XLS files protected this way, converting them to XLSX and protecting them again with a strong password is worth doing. The XLS to CSV conversion handles both legacy schemes when you provide the password.

Why removing the password first is risky

The usual workaround is to open the file, remove the password, save, convert and then delete the unprotected copy. Each step adds exposure.

• The unprotected copy lands in a downloads folder, a temp directory or a synced cloud folder.
• Synced folders may keep version history, so a deleted copy can survive.
• Someone forgets the last step, and the file stays unprotected for months.
• Email or chat attachments of the unprotected copy are outside your control once sent.

A converter that accepts the password directly removes those steps.

How XlsConverter handles protected workbooks

When you upload an encrypted workbook, XlsConverter detects the encryption and asks for the password. You type it into the password field, it travels over an encrypted connection, and it is used in memory to derive the key and decrypt the package for that one job. The password is never written to disk, never stored in the database, never logged and never kept for later jobs. After the conversion, the decrypted data is gone with the job, and the uploaded file and the result are deleted automatically, by default one hour after the job finishes.

It also helps to know what a converter can and cannot do with the password. It cannot recover a forgotten one, and it should never offer to. A service that claims to unlock files without the password is either guessing, which is slow and only works on weak passwords, or exploiting the weak legacy schemes described above.

A wrong password is reported as wrong, because the encrypted file contains a password verifier, and nothing is converted. Files stay encrypted at rest and in transit throughout. The security page describes retention and access controls in more detail, including the retention settings available on the Enterprise plan.

Protecting the output

Converting protected data creates a new file, and that file needs protection too. CSV, JSON and SQL have no encryption of their own, so the destination carries the responsibility.

• Deliver CSV or JSON to an access controlled location, such as an S3 bucket with restricted permissions, an SFTP folder or a signed webhook, rather than an open share.
• Avoid sending sensitive output as a plain email attachment.
• When the result should stay a workbook, convert to XLSX and protect it again in Excel, or produce a PDF with the XLSX to PDF converter for read only distribution.
• Delete local copies once the import is done.

Protected files in automated pipelines

Some sources send protected files on a schedule, such as a payroll provider that emails an encrypted export every month. Automation and a never stored password pull in opposite directions, and it is worth being explicit about the trade off. Because XlsConverter does not store passwords, a pipeline cannot decrypt a protected attachment on its own. The practical options are to ask the sender for an unencrypted file delivered over a protected channel, such as SFTP or a restricted bucket, or to run the protected file manually in the browser each time, which takes a minute. We consider that a fair price for never holding your passwords.

Choosing a strong password for the source

Encryption in a modern workbook is only as strong as the password behind it. The slow, repeated hashing makes guessing expensive, but a short or common password can still be found. Use a long passphrase of several unrelated words, share it through a separate channel from the file itself, such as a password manager or a phone call rather than the same email thread, and change it when people who knew it leave the team. If many files share one password, a single leak exposes all of them, so consider separate passwords per recipient or per period for the most sensitive exports.

Remember that the password protects the file only while it is encrypted. Once someone opens and saves a copy without a password, that copy is ordinary data again.

Sheet protection and hidden content

Locked sheets convert normally, because sheet protection does not encrypt anything. Two details deserve attention. Hidden sheets and hidden columns are still in the file, and a converter will read them unless you exclude them, so check which sheets and columns you export. And very hidden sheets, which do not appear in the Excel unhide menu, are also present and visible to any reader of the format.

A short checklist

1. Confirm whether the file has a password to open or only sheet protection.
2. Provide the password at conversion time instead of removing it.
3. Exclude hidden sheets and columns you do not intend to export.
4. Deliver the output to an access controlled destination.
5. Delete local copies after the import.

Protected workbooks are supported on every plan, see pricing for limits on file size and batches.