Why an image cannot hold its own password
The PDF format has encryption written into the specification, so a locked PDF is still a PDF and any reader knows to ask for a password. Image formats have nothing equivalent. There is no field in a JPEG header for a password, and no viewer anywhere that will prompt you for one.
So encrypting a photo necessarily produces a different kind of file. It is no longer an image. Your gallery will not show a thumbnail, no editor will open it, and a file manager will treat it as an unknown blob. That is exactly what encryption means: a file that nothing can read without the key. A tool that gave you back something still viewable would not have encrypted anything.
The practical consequence is that you need the matching decryption step, and it has to be somewhere you can get back to. This is why our photo encryption tool puts encrypt and decrypt on the same page rather than only handing you a locked file.
Your password is not the key
AES-256 needs a 256-bit key: 32 bytes of unpredictable data. A password is nothing like that. It is short, it is made of characters people can remember, and its possibilities are heavily concentrated in a small space. Using it directly as a key would waste most of the cipher's strength.
Instead the password goes through a key derivation function. Ours uses PBKDF2 with HMAC-SHA-256, which does something deliberately wasteful: it hashes the password over and over, hundreds of thousands of times, and uses the final result as the key.
The point of that waste is economics. Deriving the key once, when you type your password, costs a fraction of a second and you will not notice. An attacker trying to guess your password has to pay that same cost on every single candidate. Turning one hash into 310,000 hashes makes a guessing campaign hundreds of thousands of times more expensive, which is the difference between a weekend and a geological age.
The salt, and why the same photo encrypts differently every time
A random value called a salt is generated for every file and mixed into the derivation. It is stored alongside the encrypted data, unencrypted, because it is not a secret.
Its job is to make precomputation useless. Without a salt, an attacker could derive keys for a million common passwords once and reuse that table against every file in the world. A unique random salt per file means that table only ever works against one file, so it is not worth building.
A separate random value, the initialisation vector, goes into the encryption itself. Between the two, encrypting the same photo twice with the same password produces two completely different files. This is correct and intentional. If identical inputs produced identical outputs, an observer could tell that two encrypted files held the same picture without decrypting either.
What the GCM part adds
GCM stands for Galois/Counter Mode, and it provides something plain encryption does not: authentication. Alongside the ciphertext it produces a short authentication tag, computed over the encrypted data.
When you decrypt, the tag is checked first. If a single byte of the file has changed, from corruption, a failed transfer, or deliberate tampering, the check fails and decryption is refused outright.
Without authentication, encryption hides content but does not protect integrity. An attacker cannot read your file but may be able to alter it in structured ways, and you would decrypt the result and see corrupted output with no indication anything was wrong. GCM turns that into a clean, loud failure.
One practical consequence: a wrong password and a damaged file produce the same error, because from the algorithm's point of view they are the same event. The key that came out did not match the data.
Who does the actual cryptography
Not the page. Browsers ship a built-in cryptography implementation called the Web Crypto API, and that is what performs the key derivation and the encryption.
This matters more than it sounds. Cryptography implemented by hand in JavaScript is notoriously easy to get subtly wrong in ways that are invisible in testing. Using the browser's own implementation means the sensitive arithmetic is done by heavily reviewed code, and that key material can be held in a form the page itself cannot read.
It also means the work happens on your device. No part of the file and no part of the password is transmitted anywhere. You can check that by disconnecting from the network once the page has loaded and encrypting anyway.
What this does not protect
A weak password. Everything above is arithmetic around the password. AES-256 is not the part anyone would attack. If the password is guessable, all of it is decoration.
The original file. Encrypting a copy does nothing about the unencrypted photo still in your camera roll or your downloads folder.
Metadata inside the image. The file is encrypted exactly as it is, so any location data or camera information it carried comes back when you decrypt. If you do not want that data to exist, remove it before encrypting.
Forgetting the password. There is no recovery. Save it in a password manager before you close the tab.