File Encryption (AES-256)
Encrypt a file behind a password with AES-256-GCM and get back a .tray you can open on any machine. The key is stretched with PBKDF2 at 600,000 iterations.
File
Drop a file here
Any type, any size your device can hold — sealed here, nothing is uploaded
—
—
Where every byte goes
The 52 bytes that are not your file
What it needs while it runs
You will get
How to use
- Leave Direction on Encrypt. It's the side the page opens on, and the button reads Seal it so you can tell at a glance which way round you are.
- Give it your file. Any type, any extension, nothing filtered out in either direction.
- Type the password once. The hint under the field counts what you have typed until it reaches 15 characters, and the eye button shows the password so you can read it back before you rely on it.
- Press Seal it. The pause is the key being stretched; then the sealed copy is opened again with the same password, and only when it comes back byte for byte does Download .tray appear.
- Send the .tray however suits you, and send the password some other way. A password in the same email as the file is protecting nothing.
- At the other end, set Direction to Decrypt, pick the .tray, type the password and press Open it, then Download file. A renamed container opens too.
How the encryption works
Sometimes a file has to travel over a channel you don't trust. A tax return going to your accountant by email, a passport scan in a WhatsApp thread, an export of your password manager sitting in a Dropbox folder where one wrong share would be a very bad day. Encrypt a file here first and what comes out is unreadable to everyone without the password, me included. Feed it report.pdf and you get report.pdf.tray, which is exactly 52 bytes larger than what went in: an 8-byte marker reading TRAYENC1, a 16-byte salt, a 12-byte IV, and the 16-byte authentication tag that GCM appends to the ciphertext. None of those four are secret. All four are needed to get your file back.
The password isn't used as a key directly. It goes through PBKDF2 with HMAC-SHA-256 for 600,000 iterations against that random salt, which is what turns each guess into expensive work for anyone attacking the file offline, and it's also why there's a visible pause before the result appears. Because the salt and IV are freshly random every time, encrypting the same file twice gives you two .tray files that share no bytes past the marker, and neither one hints that they hold the same thing. GCM checks the ciphertext before it hands anything back, so a wrong password or a single flipped byte in transit gets you “Wrong password, or the file is corrupted.” instead of a broken PDF. There is no reset link and no copy of your password anywhere. Forget it and the file is scrap.
What a 2 MB PDF turns into
Take contract-signed.pdf at 2,097,152 bytes. Pick it and the page already says what you will get: 2,097,204 bytes, the original plus the 52 the container adds. Type a password, press Seal it, and the sealed copy is opened again with the same password before Download .tray appears. Open the saved file in a hex editor and the first eight bytes spell TRAYENC1 in ASCII; everything from byte 36 onward is ciphertext.
Coming back the other way, set Direction to Decrypt and pick the .tray. Before any password is typed the page lays out its four parts and where every byte sits. Type the password, press Open it, and Download file hands you contract-signed.pdf at its original 2,097,152 bytes.
Good to know
- There is no recovery, and that's structural rather than a policy I could bend. Your password is never stored and no key escrow exists, so nobody can open the file for you.
- The file is loaded whole, sealed in a single call and held again as output, so it sits in memory up to three times over while it runs. From 512 MB the page warns you before you press anything; multi-gigabyte archives will fail, and a phone gives up a long way before a laptop does.
- The .tray layout is mine, not a standard. 7-Zip, VeraCrypt, GPG and Disk Utility will all refuse it, so decrypt here first if you need the file in something else.
- Nothing about the name or the size is hidden. The .tray sits at the original size plus 52 bytes and carries the original name in front of the suffix, so anyone who sees it knows they're holding a 4 MB PDF called tax-2025 even though they can't read a byte of it.
- No composition rule is enforced. The hint asks for 15 characters or more and counts what you type, but a shorter password is still accepted, and there is no strength meter. The key stretching buys you time against an offline attack; it will not save a password sitting in the first thousand lines of a wordlist.
Frequently asked questions
What exactly is a .tray file?
Your file, encrypted, with a 36-byte header glued to the front. Eight bytes of the ASCII text TRAYENC1 so the decrypt side can tell it's the right kind of file, then the 16-byte salt, then the 12-byte IV. Everything after that is AES-GCM ciphertext with its 16-byte tag on the end. The salt and IV aren't secret and are meant to sit right there with the data.
Can the person I send it to open it without installing anything?
They need this page and the password, and that's the whole list. They load the tool, set Direction to Decrypt, pick the .tray, type the password, press Open it and download the original. There's no key file to exchange, because the salt and IV they need are already inside the container you sent.
How strong does the password need to be?
Fifteen characters or more, because that password is the entire lock and length is what makes guessing it expensive. PBKDF2 at 600,000 iterations makes each attempt slow, which multiplies an attacker's cost rather than repairing a weak choice. Four or five random words clears the bar easily and is simple to read out over the phone; no symbols are needed. The password generator here will produce one if you'd rather not invent it yourself.
Why does it sit there for a moment before Download .tray appears?
Key derivation, twice. Running HMAC-SHA-256 six hundred thousand times is deliberately slow, and it's the same slowness that makes brute-forcing the file expensive. It happens once to seal the file and once more to open the sealed copy and check it before you are offered it. That pause is per operation rather than per megabyte, so a small file and a large one cost about the same amount of it.
I typed the right password and it says the file is corrupted.
GCM authenticates before it decrypts, so a wrong password and a damaged file produce the identical message. Most often the .tray got mangled in transit, by a mail gateway rewriting the attachment or a chat app helpfully recompressing it. Check the byte count against what you sent, which should be the original size plus 52, and send it again inside a zip if something is rewriting it.
Does encrypting the same file twice give the same result?
No, and that's on purpose. A new 16-byte salt and a new 12-byte IV are generated for every single operation, so two .tray files built from one source and one password share nothing past the eight-character marker. An observer can't even tell you sent the same document twice.
What happens if I rename the .tray before sending it?
Decryption still works. The filename you get back changes, though, because the original name was never kept inside the container; it's just whatever sits in front of .tray. Rename statement.pdf.tray to file.tray and what decrypts is a file called file with no extension, which you'd then rename to file.pdf by hand.
Is this the same as putting a password on a PDF or a ZIP?
Different jobs. A PDF password is enforced by whichever reader opens it and plenty of them can be stripped in seconds. ZIP's older encryption has known weaknesses, and even its AES mode leaves the list of filenames readable. What comes out of here is one opaque blob with nothing legible in it, at the cost of convenience: a .tray can't be previewed, streamed, or opened by anything but this page. Protect PDF (Password) is the better call when you want the recipient to just double-click it.
Missing something in File Encryption (AES-256)? Suggest a feature →
Tell someone who needs this.