Protect file contents with encryption

To restrict access to a spreadsheet’s contents, save an ODS file with an opening password. A password that only restricts editing, a read-only suggestion, and sheet protection do not provide the same protection against reading the file.

Prepare a harmless test and a recovery copy

This procedure follows Apache OpenOffice Calc 4.1 desktop documentation with English menus. It is a documentary exercise, not a native security test or a guarantee about every file format. Use synthetic data, not sensitive records, for your first check.

Create a workbook containing A1=Practice, A2=Quantity, B2=12, A3=Rate, B3=8, A4=Total and B4 with =B2*B3. The total is 96. Save it as encryption-practice-original.ods. This disposable unencrypted original lets you recover the example without relying on password recovery.

Choose a unique, strong test password and retain it through a trusted password manager or your established secure method. Do not place it in worksheet cells, a filename, a comment, or a message to another person. This tutorial does not supply a reusable password. The official guide warns that lost opening passwords can make the contents effectively unrecoverable.

Save an encrypted copy

1. In Calc choose File > Save As.
2. Use a distinct name, encryption-practice-protected.ods, and keep the OpenDocument Spreadsheet format.
3. Select Save with password, then click Save.
4. In Set Password, fill the two password fields at the top of the dialog with the same opening password.
5. Leave the separate read-only/write-protection options alone for this exercise. Click OK.

If the two entries do not match, Calc reports an error and returns you to the password dialog. Re-enter carefully rather than saving an unprotected copy under the protected filename. Confirm the saved path and file extension before moving on.

The More Options section can set Open file read-only and a separate password for editing. Those choices solve a different problem. A file that everyone can open read-only is not equivalent to a file whose contents require a password to read.

Test the access boundary

Close the protected document completely, then open that exact file again. It should ask for the opening password before revealing the sheet. For the synthetic test only, cancel once and confirm the document does not open. Open it again, provide the correct password, and verify B4=96.

A test performed while the file is already open does not establish that a future open requires authentication. Likewise, a password prompt on a different filename proves nothing about the intended saved copy. Check the full path if you have several similarly named files.

Change B2 from 12 to 15 in the successfully opened protected copy. B4 should become 120. Save, close and reopen it again; confirm that it still requires the opening password and retains the changed input and formula. The protected copy now differs from the unencrypted baseline, whose total remains 96.

Understand what encryption does not cover

The unencrypted original still contains readable data. Creating an encrypted copy does not retroactively protect other copies, exports, emailed attachments, temporary files or printed pages. Use the synthetic original for this exercise, and apply your organization’s retention policy before working with real information.

Do not use CSV as an encrypted-workbook substitute: it cannot preserve this ODS workbook structure or the same protection workflow. If a recipient needs another format, independently verify that format’s protection rather than assuming the Save with password checkbox means identical security everywhere.

If the protected copy opens without a prompt, stop using it for confidential information. Check that you closed the document, selected the correct copy, retained ODS format and set the opening-password fields rather than only write protection. Recreate the protected copy from the disposable original if necessary.

Official reference

Apache OpenOffice 4.1 Calc Guide, Chapter 1, Password Protection. Recovered guide retrieved 19 October 2026. No password cracking, security-setting changes or native encryption assurance is claimed; this exercise verifies the intended user-visible access boundary.