The Complete Guide to File Encryption in 2026

Most people who send sensitive files use the word 'encrypted' the way they use the word 'organic' — they want it to mean something, but they're not exactly sure what. This guide will fix that. By the end you'll know what AES-256 actually does, why TLS isn't enough on its own, and how to combine three different layers of encryption to ship a file that even a determined attacker can't read.

Layer 1 — Encryption in transit (TLS)

When you upload a file to any modern web service, the connection between your browser and the server is wrapped in TLS — Transport Layer Security. The current version, TLS 1.3, encrypts every byte with strong symmetric ciphers (AES-256-GCM or ChaCha20-Poly1305) and authenticates the server with a certificate signed by a trusted authority.

TLS protects against passive surveillance — someone at a coffee shop sniffing your Wi-Fi or an ISP technician quietly logging traffic. It does NOT protect against the server itself. Once your file lands on the server, TLS is done; the operator can read it unless something else is encrypting the file on disk.

How to check you're getting TLS 1.3: in any browser, click the padlock icon in the address bar and look at 'Connection security'. If it says 'TLS 1.3', you're good. If it says 'TLS 1.2' or lower, the service is behind the times — politely complain to them.

Layer 2 — Encryption at rest (AES-256)

Once your file hits the server, a responsible operator encrypts it before writing to disk. Most cloud storage (AWS S3, Google Cloud Storage, our own Emergent storage) uses AES-256-GCM with keys managed by a dedicated key management service (KMS). The practical effect: if someone walks into the data centre with a hard drive and copies the raw blocks, they get unreadable ciphertext.

AES-256 is the gold standard. The number after AES (128, 192, 256) is the key length in bits. 256-bit keys are well beyond what current and foreseeable computers can brute-force — even a hypothetical attacker with the energy budget of the sun couldn't try every key in the universe's lifetime. The 'GCM' part is the mode of operation, which provides both confidentiality (the data is encrypted) and authenticity (the data hasn't been tampered with).

Layer 3 — End-to-end encryption (E2EE)

Layers 1 and 2 still leave a window: the moment between your file arriving at the server and being written to encrypted storage, the operator could (in theory) intercept it. They probably won't — most operators don't run such logging because it would be a liability — but it's possible.

End-to-end encryption closes that window. The file is encrypted on your device before it ever leaves, with a key the server never sees. Only the recipient — who has the matching key — can decrypt. The server holds ciphertext from start to finish.

E2EE is the gold standard for messaging (Signal, WhatsApp, iMessage) and is becoming more common for file sharing. The friction is real, though: how does the recipient get the key? The standard answer is to put the key in the URL fragment (after the `#`), because browsers don't send fragment parts to servers. The URL itself becomes the secret.

Layer 4 (DIY) — Client-side encryption for paranoia mode

If you can't wait for your file-sharing service to ship E2EE, you can do it yourself. Encrypt the file with a strong password using 7-Zip, VeraCrypt, or `gpg --symmetric`. Upload the encrypted file. Share the password through a separate channel — a voice call, an in-person handoff, a Signal message.

This is genuinely robust. Even if the storage operator wanted to read your file, they'd be staring at AES-encrypted ciphertext with no key in sight. The only attack surface left is your password — pick a long, random one (16+ characters with mixed character classes, or a passphrase like 'correct-horse-battery-staple-7').

What about quantum computers?

Symmetric algorithms like AES-256 are quantum-resistant — Grover's algorithm halves the effective key size, so AES-256 becomes 'AES-128 against a quantum attacker', which is still completely intractable. Asymmetric algorithms (RSA, ECDH — used during the TLS handshake) are NOT quantum-resistant. NIST has standardised post-quantum replacements (Kyber, Dilithium) and major TLS libraries are already piloting them. By 2027 most production traffic will use hybrid handshakes that combine a classical algorithm with a post-quantum one.

Practical recommendations

• →For everyday file sharing: TLS + at-rest encryption is fine. Pick a service that demonstrates both.
• →For sensitive personal stuff (tax forms, medical records): add a transfer password.
• →For business-critical leaks (M&A documents, source code): client-side encrypt with 7-Zip, then share the password by voice call.
• →For journalists or activists with state-actor adversaries: use Signal's file-sharing feature, which is E2EE by default.

Encryption isn't a single feature — it's a stack. The more layers you can deploy, the harder you make the attacker's job. Pick the stack that matches your risk model, and don't let perfect become the enemy of good.