How to encrypt backups before storing them on a usb or external drive
- Step 1Bundle your backup into one archive first — This tool encrypts a single file per run, so collect your backup into one container — a
.zip,.tar,.7z, disk image, or single large file. The input type isany, so the archive format does not matter to the encryptor. - Step 2Open the tool on Pro with 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 to seal the archive.
- Step 3Drop the archive — Upload the single backup archive. On Pro the size ceiling is 100 MB, Pro + Media 500 MB, Developer 2 GB. A large backup is also bounded by your device's available memory, since the whole file is processed in the browser tab.
- Step 4Set a strong, long-lived passphrase — Type a passphrase of at least 8 characters into the masked field; anything shorter is rejected with
Passphrase must be at least 8 characters.Because a backup may sit untouched for months, store this passphrase in a password manager — there is no recovery if you forget it. - Step 5Encrypt and copy the .aes to the drive — PBKDF2 derives the key from a fresh 16-byte salt; AES-GCM encrypts under a fresh 12-byte IV — all locally. Download
<archive-name>.aes(MIMEapplication/octet-stream) and copy that single blob to your USB or external drive. The plaintext never touches the drive. - Step 6Restore later by decrypting from the drive — When you need the backup, copy the
.aesoff the drive, set Mode to Decrypt (the picker then hints.aes), drop the file, and enter the same passphrase. The tool strips.aesand returns the original archive; a wrong passphrase or any corruption throwsDecryption failed — wrong passphrase or corrupted file.
Threats to a removable-drive backup, with and without AES-256-GCM
Encrypting the archive neutralises the threats that come from the drive leaving your control.
| Threat | Plain archive on the drive | AES-256-GCM `.aes` on the drive |
|---|---|---|
| Drive lost or stolen | Full data readable by finder | Ciphertext only — needs the passphrase |
| Drive sold / disposed without wipe | Recoverable plaintext | Unreadable without the passphrase |
| Bit-rot / bad sector | Silent corruption on restore | Auth tag fails — decryption errors loudly |
| Borrowed by a colleague | They can open everything | They see an opaque blob |
| Same passphrase reused per backup | n/a | Fresh salt + IV each run — every .aes differs |
Backup size vs. plan
Pick a plan that fits your archive. The tool never accepts more than one file per run regardless of plan.
| Plan | Max archive size | Files per run | Access |
|---|---|---|---|
| Free | 10 MB (family limit) | 1 | Locked — Pro overlay |
| Pro | 100 MB | 1 (no batch) | Unlocked |
| Pro + Media | 500 MB | 1 (no batch) | Unlocked |
| Developer | 2 GB | 1 (no batch) | Unlocked |
The two controls — nothing else exists
No compression option, no key-file, no schedule, no incremental setting. Only Mode and passphrase; every crypto parameter is fixed in code.
| Control | Type | Default / rule |
|---|---|---|
| Mode | Dropdown: Encrypt / Decrypt | Defaults to Encrypt |
| Passphrase | Masked password field | Minimum 8 characters |
Cookbook
Backup-and-restore recipes with the exact filenames, byte layout, and error strings the tool produces. Everything runs in your browser tab — no upload, no server, no API.
Encrypt a zipped backup before copying it to USB
Zip your documents folder, encrypt the single archive, then copy only the .aes to the stick. If the stick is lost, the finder gets ciphertext.
Step 1 zip locally -> documents-backup-2031-06.zip (74 MB)
Step 2 Mode = Encrypt, drop the zip
salt = 16 random bytes
iv = 12 random bytes
key = PBKDF2(passphrase, salt, 100000, SHA-256)
ct = AES-GCM(key, iv, archive) (tag appended)
Step 3 download documents-backup-2031-06.zip.aes
bytes = salt(16) + iv(12) + ciphertext+tag
Step 4 copy ONLY the .aes to the USB driveRestore the backup from the drive months later
Copy the .aes off the drive, decrypt with the same passphrase, then unzip. The decrypt path reads salt/IV from the first 28 bytes and strips the .aes suffix.
Mode: Decrypt Input file: documents-backup-2031-06.zip.aes (from the USB) Passphrase: (the one stored in your password manager) Downloaded: documents-backup-2031-06.zip (byte-for-byte original) -> unzip to restore If the drive corrupted a byte (bit-rot): Error: "Decryption failed — wrong passphrase or corrupted file." -> restore from a second copy instead.
Keep redundant encrypted copies on two drives
AES-GCM randomises every encryption, but you do not need to re-encrypt for redundancy — copy the same .aes to multiple drives. Each copy decrypts with the same passphrase.
Encrypt once -> photos-archive.tar.aes Copy to: USB stick photos-archive.tar.aes external SSD photos-archive.tar.aes offsite drive photos-archive.tar.aes Any copy decrypts identically. If one drive dies or rots, restore from another — same passphrase, same result.
Detect bit-rot before you trust a restore
GCM authentication catches corruption at decrypt time, but you can also fingerprint the .aes after writing it and re-check the fingerprint later to spot a degrading drive early.
After writing to USB: run photos-archive.tar.aes through Multi-Hash Fingerprinter sha-256 = a1c4f9... (record it) Months later, before relying on the drive: re-fingerprint the .aes on the drive sha-256 = a1c4f9... -> intact, safe to decrypt sha-256 differs -> drive degraded, use another copy Decryption would also fail on a changed .aes, but hashing lets you check WITHOUT typing the passphrase.
Choose a passphrase you will still have in a year
A backup may sit untouched for months. The tool enforces 8 characters minimum, but durability matters more than cleverness — store the passphrase, do not rely on memory.
Rejected: "backup1" -> 7 chars -> "Passphrase must be at least 8 characters." Weak but accepted (don't): "backup12" -> 8 chars, trivially guessable Strong, accepted, and SAVED to a manager: "granite-harbor-meadow-cipher-19" There is no reset: forget it and every copy on every drive is permanently unreadable. Save it the moment you set it.
Edge cases and what actually happens
Forgotten passphrase after months of storage
Unrecoverable by designThe passphrase is derived to a key in your browser and never transmitted, so JAD holds nothing that could open the backup. If you forget it, every copy of the .aes on every drive is permanently unreadable. Backups are the worst place to gamble on memory — store the passphrase in a password manager before you archive.
Drive bit-rot or a bad sector corrupts the .aes
Decryption failedAES-GCM authenticates the whole blob, so a single flipped byte from a degrading drive invalidates the auth tag and decryption throws Decryption failed — wrong passphrase or corrupted file. This is a feature: you learn the backup is damaged instead of restoring silently corrupted data. Keep a second copy on a separate drive.
Passphrase shorter than 8 characters
RejectedLength is checked before any crypto runs. Under 8 characters throws Passphrase must be at least 8 characters. and nothing is encrypted. It is a hard minimum in code.
Backup archive exceeds your plan's size limit
Exceeds limitThe archive is 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. Split the backup into smaller archives and encrypt each, or upgrade the plan.
Very large archive exhausts browser memory
By design (device-bound)Encryption runs entirely in the browser tab and loads the whole file, so a multi-gigabyte archive is bounded by your device's available memory even within the Developer 2 GB plan limit. If the tab runs out of memory, split the backup into smaller archives and encrypt them separately — there is no streaming mode.
Wanting to encrypt a whole folder at once
Single file onlyThere is no batch and no folder mode — the tool takes one file per run. Compress the folder into a single archive (.zip, .tar, etc.) first and encrypt that one archive. To restore, decrypt then extract. Each separate archive you encrypt gets its own random salt and IV.
Copying the plaintext to the drive by mistake
Defeats the purposeIf you copy the original archive to the drive instead of the .aes, the drive holds readable data again. Copy only the .aes blob, and confirm the plaintext archive is not also sitting on the removable media. The tool cannot manage what you choose to copy where.
Decrypting a .aes made by a different program
Decryption failedDecrypt assumes the strict layout salt(16) + iv(12) + ciphertext+tag. A .aes from VeraCrypt, 7-Zip, OpenSSL, or any other tool uses a different header and key-derivation scheme, so the first 28 bytes are not a valid salt+IV here and the tag will not verify — you get Decryption failed. This tool only round-trips its own blobs.
Renaming the .aes on the drive
ExpectedDecrypt only strips a trailing .aes to recover the filename. If you renamed backup.zip.aes to b.bin, decrypt still returns the correct bytes but cannot restore the original name. Keep the .aes suffix so the filename round-trips cleanly to backup.zip.
Re-encrypting an already encrypted .aes
SupportedNothing stops you from encrypting a .aes again — you get <name>.aes.aes wrapped in a second AES-GCM layer. To restore you must decrypt twice, in reverse order, with each passphrase. This is rarely intended; usually it means you forgot the archive was already encrypted.
Frequently asked questions
Why encrypt the archive instead of using full-disk encryption?
Full-disk encryption protects a drive only while it is locked and correctly configured; an unlocked drive, a misconfigured one, or a drive plugged into another machine can still expose data. Encrypting the archive itself with AES-256-GCM means the file is sealed independently of the drive — the .aes stays unreadable no matter where it is copied or how the drive is mounted.
What happens if the drive develops bit-rot?
AES-GCM authenticates the entire blob, so a single corrupted byte invalidates the auth tag and decryption fails with Decryption failed — wrong passphrase or corrupted file. You learn the backup is damaged rather than restoring corrupted data silently. Keep at least one redundant copy on a separate drive so a failure on one is recoverable from another.
Can I just copy the same .aes to several drives?
Yes. The .aes is self-contained (salt + IV + ciphertext + tag), so any copy on any drive decrypts identically with the same passphrase. You do not need to re-encrypt per drive — encrypt once, copy the blob wherever you want redundancy.
How large a backup can I encrypt?
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. Because everything runs in the browser and the whole file is loaded into memory, very large archives are also bounded by your device's available RAM; split them if a tab runs out of memory.
Can JAD recover my backup if I lose the passphrase?
No. The passphrase is derived to a key locally and never transmitted, so JAD stores nothing that could decrypt it. A forgotten passphrase makes every copy of the .aes permanently unreadable. Save the passphrase in a password manager the moment you create the backup — this is deliberate, not a recoverable failure.
Why does each backup encrypt to different ciphertext even with the same passphrase?
Every run generates a fresh 16-byte salt and 12-byte IV. A new salt means a different derived key even with the same passphrase, and a new IV means different ciphertext. So two backups of the same data produce unrelated .aes blobs — an observer of your drive cannot tell which backups hold identical contents.
Can I encrypt several backup files in one run?
No — the tool processes one file per run with no batch. Compress your files into a single archive first and encrypt that. To restore, decrypt the archive then extract. If you keep multiple separate archives, encrypt each one individually; each gets its own random salt and IV.
How can I check a drive copy is intact without decrypting it?
Fingerprint the .aes right after writing it with Multi-Hash Fingerprinter and record the SHA-256. Re-fingerprint the drive copy later; a match confirms the blob is unchanged, a mismatch flags drive degradation — all without typing your passphrase. For ongoing tamper/drift monitoring of stored files, see File Integrity Monitor.
Is AES-256 strong enough for a backup that sits for years?
Yes. AES-256 retains roughly 128-bit effective security even against quantum search (Grover's algorithm), which is considered safe well beyond 2030. The practical risk to a long-lived backup is a weak or forgotten passphrase, not the cipher — PBKDF2's 100,000 iterations slow guessing but cannot rescue a short passphrase. Choose a long one and store it.
How strong should the passphrase be?
The tool enforces a minimum of 8 characters but that is a floor, not a recommendation. For a backup that may sit untouched, use a long passphrase of several random words. Audit candidates with Password Entropy Auditor before committing — a stolen drive plus a weak passphrase can still be cracked offline despite the PBKDF2 iterations.
Should I compress before or after encrypting?
Always compress first, then encrypt. Encrypted output is effectively random and does not compress, so zipping a .aes saves nothing. Build your archive, encrypt the single archive, and store the .aes. You can verify a file already looks random/encrypted with Entropy Analyzer.
Will the original filename come back after restore?
Yes, as long as you keep the .aes suffix. Decrypt strips a trailing .aes, so documents-backup.zip.aes restores to documents-backup.zip. If you renamed the blob on the drive, decrypt still returns the correct bytes but cannot recover the original name — keep the suffix to preserve the round-trip.
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.