Lock a photo behind a password using AES-256-GCM, and unlock it again on the same page. The key is derived from your password on your own device, so the image and the password never travel anywhere. Free, no account, no watermark.
Encrypting a photo is not like password-protecting a PDF. The PDF format has encryption built into the specification, so a locked PDF is still a PDF. Image formats have no such thing. A JPEG has nowhere to put a password, and there is no viewer anywhere that will prompt you for one.
So this tool produces a different kind of file, ending in .kbenc. It holds your
encrypted image plus the small amount of information needed to decrypt it: the random salt, the
random initialisation vector, the iteration count and your original filename. It is not an image
any more. Your gallery will not show it and no photo editor will open it. That is the intended
behaviour, and it is the honest trade: a file nothing can open is exactly what encryption means.
To get your photo back, return to this page, switch to the Decrypt tab, and give it the same password. What comes out is byte-for-byte identical to what went in, filename included.
Your password is not used as a key directly. It is stretched into one with PBKDF2 using HMAC-SHA-256, 310,000 iterations and a fresh random 16-byte salt for every file. The iteration count follows current OWASP guidance and exists to make guessing expensive: an attacker testing passwords has to pay that cost on every single attempt.
The derived 256-bit key encrypts the image with AES-256-GCM and a fresh random initialisation vector. GCM is an authenticated mode, which matters more than it sounds. It does not only hide the contents, it also detects modification. If a single byte of the encrypted file is changed, decryption fails outright rather than quietly returning damaged data. All of this runs through the Web Crypto API that your browser already ships, so the actual cryptography is done by the browser rather than by hand-written JavaScript.
Because the salt and the initialisation vector are random each time, encrypting the same photo twice with the same password produces two completely different files. That is correct and intentional.
It suits a single sensitive image you want to store in a shared folder, keep in cloud backup, or hand to one person who can be told the password separately. Identity documents, a photo of a form, a scan of something private.
It is the wrong tool if the person receiving it cannot be told to come back to this page, if you need many files at once, or if you need something that opens in standard software. For those cases a password-protected archive, or full-disk encryption on the device itself, fits better.
There is no password recovery, by design. Forget it and the photo is unrecoverable. Save it in a password manager before you close this tab.
Encryption protects the file you downloaded, not the original. If the unencrypted photo is still in your camera roll, your downloads folder, or an already-sent message, encrypting a copy changes nothing about those. Delete the copies you do not want kept.
And a weak password undoes all of it. AES-256 is not the part anyone would attack. The password is.
No. Disconnect from the network once the page has loaded and it still encrypts and decrypts, which is the easiest way to verify that for yourself.
No. The container is specific to this tool. If you need interoperability, put the photo in a password-protected archive instead.
Yes, on any current mobile browser over https. Key derivation takes a moment longer on a phone because the iteration count is deliberately expensive.
No. The file is encrypted exactly as it is, metadata included, and the metadata comes back when you decrypt. If you want location data removed, strip it before encrypting.