Picking encryption software without first identifying the threat you are encrypting against is the most common mistake in this category, and it produces both pointless installations (encrypting against threats that do not apply to you) and false security (using the wrong type of encryption for the threat that does apply). Encryption is not a single feature you turn on for general protection; it is a specific technical defence against specific failure modes, and the same tool that works perfectly for one threat is irrelevant for another.
Three threat categories cover most realistic scenarios, and the right tool is different for each. The “stolen laptop” threat assumes an attacker gets physical possession of your unencrypted device and reads its drive contents directly. The defence is full-disk encryption, and it is now built into Windows for free, so most users do not need to install anything dedicated. The “compromised cloud storage” threat assumes your cloud provider is breached, compelled by legal process, or otherwise discloses your files; the defence is encrypting files before they leave your device, and it requires specific software. The “transmitting sensitive files” threat involves sending encrypted data through email or other channels to specific recipients who can decrypt it; the defence is per-file or per-archive encryption with key management, and it requires both you and the recipient to use compatible tooling.
This guide is structured around the threat-target pairs that actually matter. For broader context on the Windows security software stack where encryption sits among many layers, our complete guide to Windows software covers the adjacent categories.
For the Stolen Laptop Threat: Just Use BitLocker
If your concern is “someone steals my laptop and reads my hard drive,” the answer is BitLocker, the full-disk encryption built into Windows 11 Pro and Enterprise editions. The setup takes about 30 minutes (most of which is the initial encryption running in the background while you continue working), the daily user experience after setup is identical to using an unencrypted system, and the protection is genuinely strong against the physical-theft threat model.
The Windows 11 Home edition does not include full BitLocker but does include Device Encryption on supported hardware, which provides equivalent protection through a more limited interface. For most Home edition users, the built-in Device Encryption is automatically enabled on supported hardware without explicit user action.
The case for using BitLocker rather than third-party alternatives is overwhelming for this threat. The encryption is genuinely strong (AES-256 by default in current configurations). The integration with Windows is native rather than bolted-on. The recovery key system protects against forgotten passwords. The hardware acceleration (TPM-based) means the performance impact is negligible on modern systems. The maintenance and updates are handled by Windows Update.
The honest concerns with BitLocker are limited but worth noting. The recovery key is critical; losing both your password and the recovery key means losing access to your data permanently. Microsoft offers to save the recovery key to your Microsoft account during setup, which is convenient but means Microsoft has access to it if compelled. For users where this is a meaningful concern, saving the recovery key only to printed paper or to an offline storage location is the alternative, with the trade-off of risking loss.
For users on Windows 11 Pro or Enterprise editions, the recommendation is to enable BitLocker before installing any other encryption software. For users on Home edition, verify that Device Encryption is enabled and accept that as the answer for this threat. The third-party alternatives below address different threats, not this one.
For the Cloud Storage Threat: Cryptomator or Self-Encrypted Containers
The threat model where cloud storage is the concern is different and requires different tooling. Files encrypted on your local device and then synced to cloud storage are unreadable to the cloud provider, to anyone who compromises the cloud account, and to anyone the cloud provider is legally compelled to provide data to. This protection requires encrypting files before they reach the cloud, not relying on the cloud provider’s own encryption (which is generally fine against external attackers but does not protect against the provider itself).
Cryptomator (free for desktop, paid mobile apps, optional paid Pro for desktop with additional features; cryptomator.org) is the tool for this threat. It creates encrypted “vaults” that look like ordinary folders to your operating system when unlocked but appear as encrypted files to the cloud storage that holds them. You drag files into the vault, work with them normally, lock the vault when finished, and the underlying cloud sees only encrypted blobs.
The strengths of Cryptomator specifically are real. The encryption is genuinely strong and uses well-understood cryptographic primitives. The vault format is open source so the encryption can be verified by independent inspection. The integration with cloud sync (Dropbox, Google Drive, OneDrive, iCloud) works through the normal cloud client without requiring direct integration. The cross-platform support (Windows, macOS, Linux, iOS, Android) means files encrypted on one device can be accessed on others.
The realistic friction with Cryptomator is workflow-related rather than technical. Files must be inside an unlocked vault to be readable; this means a specific workflow where you unlock the vault when starting work and lock it when stopping. For users who genuinely treat sensitive content as separate from everyday content, this workflow is natural. For users who try to use Cryptomator for everything and resent the unlock-lock cycle, the tool produces friction without proportionate benefit.
The case against using Cryptomator is when the threat model does not actually involve the cloud provider. If your concern is purely about external attackers on your cloud account (rather than the provider itself), strong account passwords and two-factor authentication produce most of the protection without the workflow cost of encryption. Our password manager comparison covers the credential layer that often matters more than encryption for protecting cloud accounts.
For the Specific File Sharing Threat: VeraCrypt or 7-Zip
The third threat scenario involves sending specific encrypted files or archives to known recipients through email, file transfer, or physical media. The defence is per-file or per-archive encryption with key sharing handled out-of-band.
VeraCrypt (free, open-source; veracrypt.fr) is the option for users who specifically want strong encryption with broad cross-platform support and the ability to create encrypted containers that work like virtual drives. The tool is the successor to the older TrueCrypt project and remains the strongest open-source choice for users who specifically need its capabilities.
The use cases where VeraCrypt makes specific sense: creating encrypted containers on portable drives that can be unlocked on any Windows, Mac, or Linux system; encrypting partitions on external drives where the entire drive needs protection rather than file-by-file; situations where the open-source provenance matters more than convenience features. The technical capabilities are deep — hidden volumes for plausible deniability, key file authentication alongside passwords, multiple cascading encryption algorithms.
The realistic friction is that VeraCrypt’s interface and workflow show its technical heritage. The tool assumes users understand concepts like encrypted volumes, mount points, and the difference between encrypting files versus encrypting containers. For users comfortable with that level of technical detail, VeraCrypt is excellent; for users who want install-and-encrypt simplicity, the friction is real.
7-Zip (free, open-source; 7-zip.org) is the right answer for the simpler case of encrypting an archive that you will send to someone. The tool is primarily an archive utility (creating ZIP, 7Z, and other compressed archives), but it includes strong AES-256 encryption when creating 7Z format archives with a password. The workflow is straightforward: right-click files, “Add to archive,” set the password, send the resulting file. The recipient extracts using 7-Zip or any compatible tool with the password you have communicated through a separate channel.
The case for 7-Zip specifically is when the use case is genuinely “send these files securely to this person.” The friction is minimal, the recipient does not need to install Cryptomator or VeraCrypt to receive encrypted content (they just need 7-Zip or any compatible archive tool, which most people have). The encryption is strong when used with a long password and the 7Z format.
The limitations of 7-Zip for broader use are real. The password must be shared out-of-band with the recipient, which is a key management problem at scale. The protection ends once the recipient has decrypted the archive — there is no ongoing protection of the data on the recipient’s system. For one-time secure delivery, these limitations are acceptable; for ongoing secure collaboration, the better-fitting tools are different.
For Email Specifically: GPG and Modern Alternatives
Encrypted email is a specific use case worth treating separately because the historical solutions (GPG/PGP) are powerful but unusable, and the modern alternatives sacrifice some properties for usability.
GnuPG (free, open-source; gnupg.org) is the open-source implementation of the PGP standard for email encryption. The cryptography is strong, the protocol has been refined over decades, and the tooling has improved meaningfully in recent years. For users who specifically need traditional PGP-encrypted email — communicating with journalists, security researchers, or others in technical contexts that expect PGP — GnuPG with a friendly client like Thunderbird’s built-in OpenPGP support is the right path.
The case against GPG for general use is honest: the key management is genuinely complicated, the user experience after initial setup is still less smooth than ordinary email, and the population of recipients who can receive encrypted email through this protocol is small. For most users wanting “encrypted email,” the realistic answer is using an end-to-end encrypted email service rather than retrofitting encryption onto traditional email.
ProtonMail and Tutanota are the established end-to-end encrypted email services. Both encrypt email between users of the same service automatically and provide mechanisms (password-protected emails, optional GPG integration) for communicating with non-users. For users whose main goal is communicating with specific contacts privately, agreeing on a shared service is operationally simpler than the GPG approach.
The pragmatic recommendation: for occasional encrypted email to specific contacts, agree on a method out-of-band rather than committing to one infrastructure. For ongoing private correspondence with multiple people, an end-to-end encrypted service produces better outcomes than retrofitted encryption on standard providers.
What People Misunderstand About Encryption
Three common misconceptions worth addressing because they produce both wasted effort and false security.
“My data is encrypted in the cloud” rarely means what users think it means. Most cloud providers encrypt data “at rest” (stored on their servers) and “in transit” (moving between you and them), but they hold the encryption keys themselves. This protects against external attackers stealing the storage hardware but does not protect against the provider being compelled to provide your data, against insider access at the provider, or against the provider being compromised. True end-to-end encryption where the provider cannot read your data requires either specific tooling like Cryptomator on top of standard cloud storage, or providers specifically built around zero-knowledge architecture (Tresorit, Sync.com, and others discussed in our cloud storage for business comparison).
“Strong password equals encryption” is a category error that confuses authentication with confidentiality. A strong password protects access to systems; encryption protects the data itself from being readable even if access controls fail. They are complementary defences, not substitutes. Files protected only by strong passwords on accounts can still be readable to anyone who bypasses the account access; encrypted files remain protected even if account access is compromised.
“My phone is encrypted by default so I do not need to think about it” is partially correct. iOS devices and modern Android devices do encrypt by default with strong protections. However, encrypted backup of those devices to cloud services (iCloud, Google) is more nuanced — some backup content is encrypted in ways the provider cannot read, some is not, and the specific configuration matters. For users with sensitive data on phones, understanding the actual backup encryption posture is worth doing.
Key Management: The Hard Problem
Encryption fundamentally shifts the problem from “protecting the data” to “protecting the key that protects the data,” and the key management problem is what makes encryption hard to deploy well in practice.
For BitLocker, the key management decision is where to store the recovery key (Microsoft account, printed paper, offline drive, organisation’s key management system). Each choice has different trade-offs in convenience versus security posture. There is no universally right answer; the right choice depends on your threat model and operational situation.
For VeraCrypt and 7-Zip, the key is typically a password you remember. Strong passwords for encryption need to be substantially stronger than typical online passwords because attackers attempting to decrypt encrypted files can typically attempt unlimited password guesses (unlike online accounts where rate limits and lockouts protect against guessing). A 20+ character random passphrase is roughly the minimum for serious encryption use; weaker passwords substantially reduce the protection.
For Cryptomator, the vault password is similarly critical. Most users should generate this with a password manager rather than choosing it themselves, both because random generation produces stronger passwords and because the password manager handles the “what password is this” problem when you need to enter it.
For GPG, the key management is the most complex — keys need to be generated, backed up, distributed to correspondents, occasionally renewed, and protected with passphrases. The complexity is the reason GPG has remained niche despite being technically excellent. Our Windows backup software comparison covers the broader question of how to back up encryption keys themselves, which is a problem that breaks the encryption if not handled.
Performance and Operational Considerations
One practical concern: encryption has performance implications that affect different use cases differently. Modern hardware-accelerated AES encryption (which all the tools above can use) imposes negligible performance penalty on routine file operations. Full-disk encryption with BitLocker is essentially invisible in performance terms on systems with proper hardware support.
The places where encryption performance becomes visible: very large file operations (encrypting a 100 GB video file the first time), older hardware without AES instructions in the CPU (rare in modern systems but possible on older laptops), and very high-throughput workflows where the small per-operation cost adds up.
For the typical user with modern hardware and ordinary file workflows, encryption performance is a non-issue. The conversation about encryption performance that dominated 2010-era discussions is largely obsolete; the hardware support has caught up.
The operational consideration that does matter: encrypted backup recovery is harder than unencrypted backup recovery. If you back up an encrypted system and then need to recover from the backup, you need both the backup data and the encryption keys, ideally stored separately from each other. Backup systems that include the encryption keys with the backup data partially defeat the purpose of the encryption. The discipline of separate key storage is worth maintaining even though it adds operational complexity. Our VPN comparison covers another category where the operational discipline often matters more than the tool selection.
The Practical Recommendation
For most readers, the right encryption posture is layered and threat-specific. Enable BitLocker (or Device Encryption on Home editions) for full-disk encryption against physical-theft threats; this is free, built-in, and provides the most important baseline protection. For sensitive content syncing to cloud services, add Cryptomator vaults specifically for that content. For sending encrypted files to specific recipients, use 7-Zip with a strong password for the simple case or VeraCrypt for cases requiring more sophisticated capability. For encrypted email, use an end-to-end encrypted email service for ongoing communication or GPG when specific recipients require it. The wrong move is trying to encrypt everything with one tool, or encrypting nothing because the category seems complicated. Identify the specific threats that matter for your situation, pick the appropriate tool for each, and accept that encryption is one defence layer among many rather than a complete security solution. Our malware removal tool comparison covers the related security category for the threats that encryption alone cannot address.
