How to Encrypt a File Before Sharing It

There is a meaningful difference between "this file asks for a password" and "this file is cryptographically protected." Some archive formats apply legacy or weakened protection whose details have aged badly; some apply encryption without authentication, meaning an attacker who cannot read the file can still modify it undetected. Modern authenticated encryption — AES in GCM mode — provides both confidentiality and integrity: the content is unreadable without the key, and any tampering with the ciphertext is detected rather than silently decrypted into corrupted output.

AES (the Advanced Encryption Standard) is the symmetric cipher that secures most of the world's TLS traffic, disk encryption, and government data classified up to TOP SECRET. "256" refers to the key length in bits. Symmetric means the same secret — the key — encrypts and decrypts, which is what makes it practical for a file you will later open yourself. There are no known practical attacks against AES-256; the realistic risk in a well-implemented file encryption scheme is never the cipher, it is everything around the cipher: the key, the password, and the human.

A password is a short, human-chosen string; a key is 256 bits of uniformly random data. Bridging the two is the job of a key derivation function, and the difference between doing it well and badly is the difference between a scheme that resists brute force and one that invites it. If a password were hashed once into a key with a fast hash, an attacker could try billions of password guesses per second against the stolen ciphertext. A proper derivation function is deliberately slow.

PBKDF2 (Password-Based Key Derivation Function 2) is the standard construction: it applies a hash function to the password and salt tens or hundreds of thousands of times, each iteration depending on the last. A hundred thousand iterations makes each guess a hundred thousand times more expensive, moving an attacker's throughput from billions per second to thousands. The salt — a random value stored alongside the ciphertext — ensures that the same password produces a different key every time, which defeats precomputed tables and makes identical files encrypt differently.

The practical takeaway for a user: the strength of an encrypted file is the strength of the weakest link, and the password is almost always that link. A 256-bit key derived from a six-character password offers six characters of protection. So before you encrypt anything, generate a long random password — twenty characters or more, from a cryptographic source — and store it in your manager. The File Encryption tool on this site pairs naturally with the Password Generator.

A well-formed encrypted file carries more than ciphertext. It contains the salt used for derivation (safe to store — it only prevents precomputation, it does not help decryption), the parameters of the derivation (iteration count, algorithm identifiers, so the file can be opened years later when defaults have moved on), a random initialisation vector for the cipher mode, the ciphertext itself, and an authentication tag produced by GCM.

The authentication tag is the part people overlook. When you decrypt, GCM recomputes the tag and compares it before releasing any plaintext. If a single bit of the ciphertext has been flipped — by corruption, a malicious intermediary, or a bad sector — the tag check fails and the operation refuses, rather than handing you subtly damaged data you might not notice. For files that matter, "detects tampering" is as valuable as "hides content".

Open the File Encryption tool, choose your file, enter the password you generated, and encrypt. The operation runs locally in your browser using the Web Crypto API, so the file and its key never leave your device during the operation. The output is an opaque .enc blob that is safe to send through any channel.

Before you share the encrypted file, confirm you can actually open it. Decrypt it to a temporary copy using the same tool and the same password, and confirm the content matches. A checksum of the original taken before encryption — with the Checksum Generator — gives you an independent way to confirm the decrypted output is byte-identical.

This step catches the one reality that has no undo: there is no password recovery. The key exists only as a function of your password; lose the password and the file is gone — not "hard to open," gone, by mathematical necessity. Anything that could recover it would also let an attacker recover it. Verifying the round trip while you still have the original and the password in front of you is the discipline that prevents that loss.

The second reality is scope. Encryption protects content, not existence: an observer can still see that you have a file, roughly how large it is, and — depending on where you store it — possibly its filename. If the metadata around a file is itself sensitive, the remedy is operational: neutral filenames, and storage you control.

Suppose you must send a signed contract to an accountant. You generate a 24-character password with the Password Generator and store it in your manager. You load the PDF into the File Encryption tool, enter the password, and produce a contract.pdf.enc file of roughly the same size as the original — ciphertext is approximately the plaintext length plus a small fixed overhead for the salt, IV, and authentication tag.

Before you share anything, you decrypt contract.pdf.enc back to a temporary copy using the same password and confirm the content matches the original — ideally with a checksum from the Checksum Generator taken before encryption, so you verify byte-identity rather than trusting your eyes. This round-trip check catches the one failure that has no recovery: a password you mistyped at encryption time, which would make the file permanently unrecoverable.

Then you split the channels. You email the .enc file as an attachment — safe, because the file is ciphertext. You send the password through a different channel: a phone call, a secure message, or a separate email to a different address. The principle is that an attacker who intercepts one channel gets either an unreadable file or a useless password, but never both. A file and its password in the same message is a locked door with the key taped to it — the encryption did nothing. The discipline of channel separation is what makes the cryptography actually deliver its promise.

Then transmit or store as convenient. The encrypted file is safe in email attachments, cloud folders, and USB sticks alike, because the protection travels inside the file rather than depending on the channel. Tell the recipient the password through a different channel than the file — a file and its password in the same message is a locked door with the key taped to it.

That one habit, more than any technical detail, is what makes file encryption deliver what it promises. Browser-based encryption is excellent for individual files: strong, fast, and private, with the operation happening on your own machine. It is not a substitute for full-disk encryption, managed organisational key custody, or compliance frameworks with specific requirements — those are infrastructure decisions. For "I need to send this document somewhere safely" or "I want this backup to be unreadable if the drive walks away," a file-level AES-256-GCM tool is exactly the right instrument.

For multiple files, encrypt each with its own password rather than reusing one across the set. A single compromised password then exposes only one file, not the entire archive, and the blast radius of a leaked credential stays bounded. The discipline is the same per file — generate a strong password, encrypt, verify the round trip, and share the password through a separate channel — repeated for each document rather than shortcut with one shared secret.

It is also worth understanding the difference between file-level encryption and the encryption your operating system may already provide. Full-disk encryption protects everything on a device when it is powered off, which is excellent protection against a stolen laptop but does nothing for a file you deliberately send elsewhere. File-level encryption travels with the file, so it protects the data wherever it goes — in transit, in cloud storage, on a USB stick handed to a colleague. The two layers complement each other: full-disk encryption for data at rest on your devices, file-level encryption for data in motion beyond them.