Learn · Practical guides
How to send sensitive documents (tax forms, IDs) without email
Encrypt files before they leave your device: attachments in a sealed message up to 5 MB, or an AES-256 archive for anything larger, with the key sent separately.
To send a tax form, an ID scan or a contract without using email, encrypt the file before it leaves your device and send the key by a different route than the file. For files up to MB in all (up to files), cipher.ink does this in the browser. You attach the files to a message and they're encrypted with it, then the person opens a link and types a passphrase. For anything larger, put the files in an encrypted archive, send that any way you like, and send the password separately. Below you'll find how each works, what to check first, and the mistakes that undo the protection.
Why email is the wrong place for these
As far as the provider is concerned, an email attachment sits unencrypted in the sender's sent folder, the recipient's inbox, every backup and every device that syncs the mailbox. A scan of a passport or a tax return can stay in those places for the rest of your life, one phished password away from anyone. Some mail servers also scan attachments, and a few relay hops may be unencrypted. If you encrypt the file first, a copy found in a mailbox is useless without the key (what email encryption does and does not cover).
Option 1: cipher.ink, for files under MB
- Attach the files. Press Attach, drag files onto the page, or paste a screenshot. The limit is files and MB in total. Each file is encrypted in your browser, with its own random IV, before anything is uploaded, so the server stores ciphertext and never learns the file names or the contents (AES-GCM).
- Write a line of context if the person needs one, such as "Signed form, page 1 to 3".
- Choose a passphrase lock (the dice make a strong one), set a short expiry, and consider Burn after reading. With burn, the message is deleted from the server when it's opened. The files can be fetched once each for minutes after that, so a download that has already started isn't lost.
- Seal it, and send the link and the passphrase by different routes, say an email for the link and a phone call or text message for the passphrase.
- The recipient opens the link, types the passphrase and sees the images inline, and each file has a Save button. The files are decrypted in their browser.
The password guide walks through the same steps with screenshots of each screen. The scrambled data is held until the message is opened or its timer ends, and then it's deleted. Every limit and edge, including what the server can see (size, time, IP address), is on the security page.
Option 2: an encrypted archive, for anything bigger
Put the files in one archive encrypted with a password, then send the archive however you like: a file-sharing link, a USB stick, a cloud drive. The archive's own encryption does the protecting, so the route it takes matters far less. The method matters a great deal, though, because some common ones are weak:
- 7-Zip, with AES-256. The 7z format uses AES-256 and can hide file names too.
7z a -p -mhe=on documents.7z folder/asks for a password and encrypts the file list as well as the contents. For a .zip that other people can open anywhere, use7z a -tzip -p -mem=AES256 documents.zip folder/. - Avoid the "classic" ZIP password. Many tools, including the command-line
zip -e, can still produce the old ZipCrypto scheme. Eli Biham and Paul Kocher broke it in 1994. With a few bytes of known file contents, the key can be recovered, and free tools do it. Check what you made with7z l -slt documents.zip, which shows "ZipCrypto" or "AES-256" for each entry. - An encrypted disk image on a Mac. Disk Utility can make an image from a folder with 256-bit AES encryption. The recipient needs a Mac, or a tool that can read it.
- GnuPG or age.
gpg --symmetric --cipher-algo AES256 fileorage -p -o file.age fileencrypts one file with a passphrase. They're excellent and unfamiliar to most recipients, so use them with people who already know them.
Then send the password separately, as a short self-destructing message, and not in the same email as the archive. Make it long and random. A passphrase of five or six random words is strong and easy to read over the phone (how to make one).
Before you send anything
- Send only what's needed. A bank asking for proof of address doesn't need your whole tax return. Crop or redact the rest.
- Strip hidden data. Photos carry location and camera details in their EXIF data, and PDFs and Word files carry author names and edit history. Take a screenshot of a page instead of attaching the original, or use the export option that removes metadata.
- Mark the copy. On a scan of an ID, writing "For [purpose] only, [date]" across it makes a leaked copy harder to misuse, though it won't stop all fraud.
- Check who really needs it. A request for documents that arrives by email, especially an urgent one, may be phishing. Contact the organization by a number you already know.
- Delete your own copies of what you no longer need, in the downloads folder, the cloud sync and the "sent" copy of any email.
What this won't protect against
Encryption protects the files in transit and at rest on the server, not on the recipient's device. Once they're opened, the person can save, forward or print them, and they're only as safe as that person's laptop and habits. A message that burns after reading limits the time the encrypted copy exists online, not what the recipient does next. For legally sensitive or regulated documents, where rules govern how they must be handled, follow those rules. This guide isn't legal advice.
Common questions
Is a password-protected PDF safe enough?
It depends on the version. Modern PDFs with AES-256 are sound if the password is strong, but older PDFs use weak 40-bit or 128-bit RC4 encryption, and the "restrictions" on printing can be removed. When in doubt, put the PDF in an encrypted archive or attach it to a sealed message.
Can I send a video with this?
Only if it's under MB in total. Longer videos go in an encrypted archive, or on a cloud drive with a link you protect with a password.
Does the server learn the file names?
No. File names are inside the encrypted payload. The server can see that a message exists, its approximate size and when it was made.