How to encrypt files to send to a client over email
- Step 1Open the tool on Pro and keep Mode on Encrypt — The AES-256 Encryptor requires the Pro plan; on Free a Pro overlay blocks it. The Mode dropdown defaults to Encrypt — leave it there. You only switch to Decrypt when you are the one receiving an
.aesfile. - Step 2Drop the single file you want to send — Upload the one attachment — input type is
any, so a PDF contract, a DOCX, a ZIP of evidence, or an image all work. This tool processes one file at a time (no batch). On Pro the size ceiling is 100 MB (Pro + Media 500 MB, Developer 2 GB). - Step 3Choose a passphrase you can dictate over the phone — Type a passphrase of at least 8 characters into the masked field (placeholder
At least 8 characters). Anything shorter is rejected withPassphrase must be at least 8 characters.Pick something the recipient can receive cleanly by voice — several words separated by hyphens beats a string of random symbols you both will mistype. - Step 4Encrypt and download the .aes blob — PBKDF2 derives the key from your passphrase and a fresh 16-byte salt; AES-GCM encrypts under a fresh 12-byte IV — all in your browser. You get back
<original-name>.aes(MIMEapplication/octet-stream) containing salt + IV + ciphertext + tag. - Step 5Email the .aes file, deliver the passphrase separately — Attach the
.aesblob to your email and send it. Do not put the passphrase in the same email — text it, call it, or send it over a messaging app. If the email is intercepted, the ciphertext is useless without the separately delivered secret. - Step 6Recipient sets Mode to Decrypt and recovers the file — The recipient opens the same tool, switches Mode to Decrypt (the file picker then also hints
.aes), drops the attachment, and enters the passphrase you gave them. On success the tool strips the.aessuffix and returns the original; a wrong passphrase throwsDecryption failed — wrong passphrase or corrupted file.
What email exposes vs. what AES-256-GCM sends instead
Encrypting before send moves the only readable copy of the data out of the email path entirely.
| Point in the path | Plain attachment | AES-256-GCM `.aes` attachment |
|---|---|---|
| Your Sent folder | Original file, readable | Ciphertext only — passphrase never stored |
| SMTP relays in transit | Readable unless every hop has TLS | Opaque blob regardless of transport security |
| Mail provider storage | Indexed, scannable, breach-exposed | Unreadable ciphertext, nothing to index |
| Recipient inbox | Original file at rest | Ciphertext until they actively decrypt |
| Intercepted in transit | Full data disclosed | Useless without the separately delivered passphrase |
The two controls — nothing else exists
There is no key-file upload, no recipient-address field, no expiry setting, no cipher menu. Only Mode and passphrase are exposed; every crypto parameter is fixed in code.
| Control | Type | Rule | Sender vs. recipient |
|---|---|---|---|
| Mode | Dropdown: Encrypt / Decrypt | Defaults to Encrypt | Sender uses Encrypt; recipient switches to Decrypt |
| Passphrase | Masked password field | Minimum 8 characters | Both sides must type the exact same value |
Delivery channel pairing
Channel separation is the whole point — never send ciphertext and passphrase through the same medium.
| Ciphertext channel | Safe passphrase channel | Unsafe (do not use) |
|---|---|---|
| Email attachment | Phone call or SMS | A second email / a reply in the same thread |
| Shared cloud-drive link | Signal / WhatsApp message | A note in the same cloud folder |
| Slack / Teams file | Spoken in a video call | A DM in the same workspace |
Cookbook
End-to-end send-and-receive recipes with the exact filenames, byte layout, and error strings the tool produces. Everything runs in the browser tab on both sides — no upload, no server, no API.
Encrypt a contract before emailing it to a client
You need the client to see a draft agreement, but email it and your provider, their provider, and every relay can read it. Encrypt locally, attach the .aes, deliver the passphrase by phone.
Mode: Encrypt Input file: service-agreement-draft.pdf (820 KB) Passphrase: maple-river-ledger-7 Local steps: salt = 16 random bytes iv = 12 random bytes key = PBKDF2(passphrase, salt, 100000, SHA-256) ct = AES-GCM(key, iv, file) (tag appended) Downloaded: service-agreement-draft.pdf.aes bytes = salt(16) + iv(12) + ciphertext+tag Email the .aes; phone the passphrase to the client.
Client receives and decrypts it
The client opens the same tool — no account needed — switches Mode to Decrypt, drops the attachment, and types the passphrase you read out over the phone.
Mode: Decrypt Input file: service-agreement-draft.pdf.aes Passphrase: maple-river-ledger-7 Downloaded: service-agreement-draft.pdf (byte-for-byte original) Mistyped the passphrase by one character? Error: "Decryption failed — wrong passphrase or corrupted file." -> just re-enter it; nothing was consumed or corrupted.
Bundle several files into one encrypted attachment
This tool encrypts one file per run with no batch. To send a folder of documents, zip them first, then encrypt the single archive — the recipient unzips after decrypting.
Step 1 zip the deliverables locally:
onboarding-pack.zip (id-scan.png, w9.pdf, nda.pdf)
Step 2 Mode = Encrypt, drop onboarding-pack.zip
-> onboarding-pack.zip.aes
Step 3 Email onboarding-pack.zip.aes
Step 4 Recipient: Decrypt -> onboarding-pack.zip -> unzip
One passphrase protects the whole pack; one attachment to send.Confirm the client received an untampered file
GCM already rejects a tampered blob outright, but if you want a visible match across the round-trip, fingerprint the original and have the client fingerprint their decrypted copy.
You, before sending: run service-agreement-draft.pdf through Multi-Hash Fingerprinter sha-256 = 3b8c1a... (read it to the client too) Client, after decrypting: run the decrypted PDF through the same tool sha-256 = 3b8c1a... <- matches -> exact same file arrived If GCM had rejected a tampered .aes, decryption would have failed before the client ever saw a file to hash.
Pick a passphrase that survives being spoken aloud
You will dictate this over a phone line. Symbol-heavy passwords get mis-heard; a few hyphenated words travel cleanly and still carry high entropy. Audit it before you commit a file.
Hard to dictate, error-prone: "X7$kq!2vP" -> "was that dollar or pound? caps or lower?" Rejected outright: "acct24" -> 6 chars -> "Passphrase must be at least 8 characters." Easy to say, strong, accepted: "copper-anchor-violet-quartz" Tip: paste a candidate into Password Entropy Auditor to check its bits of entropy before you send a file under it.
Edge cases and what actually happens
Recipient mistypes the passphrase you dictated
Decryption failedA single wrong character means a different derived key, so the GCM auth tag fails to verify and the tool throws Decryption failed — wrong passphrase or corrupted file. Nothing is consumed — the recipient just re-enters the correct passphrase. This is why a few clear hyphenated words beat a string of ambiguous symbols when you have to dictate over the phone.
Passphrase shorter than 8 characters
RejectedThe tool checks length before doing any crypto. A passphrase under 8 characters throws Passphrase must be at least 8 characters. and nothing is encrypted. It is a hard floor in code, not a warning you can dismiss.
A mail relay or scanner alters the attachment
Decryption failedBecause AES-GCM is authenticated, any byte changed by a relay, an antivirus rewrite, or a corrupting transfer invalidates the auth tag and decryption fails with the same Decryption failed message. The recipient never gets silently corrupted plaintext — integrity is all-or-nothing, so a failure is your signal to re-send.
Mail provider blocks or strips the .aes attachment
By design (provider-side)Some providers quarantine unrecognised binary attachments. The tool's output is application/octet-stream, which a few filters dislike. If the .aes is stripped, zip it (file.aes -> file.aes.zip) or share it via a cloud-drive link instead and still deliver the passphrase separately. The tool cannot change how a given mail provider treats attachments.
Passphrase accidentally sent in the same email
Defeats the protectionEncryption is pointless if the passphrase rides along in the email body or a reply. Anyone who reads the message reads both halves. Always deliver the passphrase over a different channel — a call, an SMS, a messaging app. This is a workflow rule, not something the tool can enforce for you.
Recipient leaves Mode on Encrypt
Wrong directionIf the recipient forgets to switch to Decrypt, dropping the .aes re-encrypts it into file.aes.aes instead of recovering the original. There is no error — the operation succeeds in the wrong direction. The fix is to set Mode to Decrypt first; the picker then hints .aes files as a reminder.
Attachment larger than the recipient's or your plan limit
Exceeds limitFiles are size-checked before encryption. On Pro the ceiling is 100 MB (Pro + Media 500 MB, Developer 2 GB). Over the limit you get File "<name>" is <size> — exceeds the <limit> limit for your plan. Note most email providers cap attachments around 25 MB anyway, so a large .aes usually needs a cloud-drive link regardless.
Recipient is on the Free plan
Pro requiredDecrypting also requires the Pro plan — the AES-256 Encryptor has a minimum tier of Pro for both directions. On Free a Pro overlay reads AES-256 Offline Encryptor requires the Pro plan. Tell your recipient they need Pro to open the .aes, or decrypt it yourself and re-share through a channel they trust.
Recipient renamed the .aes before decrypting
ExpectedDecrypt only strips a trailing .aes to recover the filename. If the recipient saved the attachment as download.bin, decrypt still returns the correct bytes but cannot restore the original name — it just removes a .aes suffix if present. Ask them to keep the .aes suffix so the original filename round-trips.
You want to send to several clients with one passphrase
Supported, but discouragedYou can email the same .aes to multiple recipients and give them all the same passphrase — the tool does not bind a blob to a recipient. But a shared passphrase means any one of them (or anyone who phishes it) can open the file. For genuinely different recipients, encrypt separate copies under separate passphrases.
Frequently asked questions
Why not just rely on my email provider's encryption?
Provider encryption typically protects the connection (TLS) and storage-at-rest under the provider's own keys — which means the provider can still read your file, and so can anyone who breaches that account or compels the provider. Encrypting the attachment yourself with AES-256-GCM means only ciphertext ever enters the mail path, and only someone with your separately delivered passphrase can open it.
Does the recipient need a JAD account or any software?
They need the same browser tool on the Pro plan and the passphrase you delivered separately — nothing else. There is no plugin, no key exchange, no account linking. They switch Mode to Decrypt, drop the .aes, type the passphrase, and get the original back, all in their own browser tab.
How should I send the passphrase to the recipient?
Over a different channel than the file. If the .aes goes by email, deliver the passphrase by phone call, SMS, or a messaging app. The security depends on channel separation: intercepting only the email yields ciphertext nobody can open, and intercepting only the passphrase yields a secret with no file attached.
What exactly is in the .aes file the recipient gets?
One self-contained stream: salt (16 bytes) + IV (12 bytes) + ciphertext with the GCM authentication tag appended, MIME application/octet-stream. To decrypt, the tool reads the first 16 bytes as salt, the next 12 as IV, and the rest as authenticated ciphertext. The recipient needs nothing external except the same passphrase.
What if the attachment is altered or corrupted in transit?
AES-GCM is authenticated, so any change to the salt, IV, ciphertext, or tag invalidates the auth tag and decryption fails with Decryption failed — wrong passphrase or corrupted file. The recipient never gets silently corrupted output — a failure tells you to re-send the file.
Can I send multiple files in one go?
Not directly — this tool encrypts one file per run with no batch queue. Zip the files into a single archive, encrypt that one archive, and send it; the recipient decrypts then unzips. One passphrase protects the whole bundle and you send a single attachment.
Can JAD recover the file if the recipient loses the passphrase?
No. The passphrase is derived to a key in the browser and never transmitted, so JAD holds nothing that could decrypt the file. If the passphrase is lost, the .aes is permanently unreadable — store it in a password manager and share it carefully. This is deliberate, not a recoverable failure.
Is there a size limit on what I can send?
The tool requires Pro (100 MB per file), with Pro + Media at 500 MB and Developer at 2 GB. Over the limit you get File "<name>" is <size> — exceeds the <limit> limit for your plan. Separately, most email providers cap attachments near 25 MB, so larger .aes blobs usually need a cloud-drive link with the passphrase still sent separately.
Should I use this or PGP for sending to a client?
Use the AES-256 Encryptor when you can deliver a shared passphrase over a separate channel and the recipient has no PGP setup — it is the lowest-friction option. If the recipient already has a public key and you want to encrypt to that key without sharing any secret, use PGP Message Signer instead. For most ad-hoc client sends, the passphrase approach is faster.
How do I confirm the client received the exact file I sent?
Fingerprint the original before encrypting and have the client fingerprint their decrypted copy with Multi-Hash Fingerprinter; matching SHA-256 digests prove a lossless round-trip. GCM would already have rejected a tampered blob, so a hash match confirms both integrity and that the right file arrived.
What passphrase should I choose if I have to read it aloud?
A few unrelated words joined by hyphens, like copper-anchor-violet-quartz — easy to dictate, hard to guess. Avoid symbol-heavy strings that get mis-heard over a phone line. The tool enforces a minimum of 8 characters; audit any candidate with Password Entropy Auditor before committing a file to it.
Can I tell whether a file already looks encrypted before I send it?
Yes — already-encrypted or compressed data has near-maximal entropy. Run a file through Entropy Analyzer to see whether its bytes already look random (a sign it is encrypted/compressed) before you wrap it in another AES-GCM layer. Double-encrypting works but is rarely what you want.
Privacy first
Every JAD Security operation runs entirely in your browser. Files, passwords, and PGP private keys never leave your device — verified by zero outbound network requests during processing.