Your photo or video is unencrypted only on the device that holds it. That device encrypts it before it is uploaded anywhere, then writes the encrypted bytes directly to object storage using a short-lived, single-use link — the upload does not pass through PhotoLog's own application servers on its way there, and storage receives and keeps only that encrypted file, never the original.

The claim, stated precisely

PhotoLog encrypts your photos and videos on the device doing the uploading, before the file goes anywhere. Your device then writes the already-encrypted bytes directly to object storage, using a short-lived, single-use link — the upload does not pass through PhotoLog’s own application servers on its way there.

This is deliberately a statement about where encryption happens and which path an upload takes — both are mechanism, and both are verifiable from the architecture that produces them. It is not a statement about what an operator could or couldn’t do with a modified copy of PhotoLog’s own application. That is a different question, and it is answered further down this page rather than folded into this one.

Where encryption happens

Encryption happens on your device, inside PhotoLog’s application, before your file is uploaded anywhere. The file is read locally, encrypted locally, and only the resulting encrypted bytes ever leave your device. Your device asks PhotoLog for a short-lived, single-use upload link and then writes those encrypted bytes straight to object storage using that link — the file’s bytes travel from your device to storage directly, not through PhotoLog’s own application servers along the way.

This is the one encryption story this page tells: on-device, before upload, straight to storage. If you read anywhere else that a storage partner or vendor performs the encryption on PhotoLog’s behalf, that is not how PhotoLog’s architecture works, and it is not accurate.

How your keys are organized

Rather than one key for your whole account, PhotoLog builds a small hierarchy of keys, each with a narrower job than the one above it:

Your account secret is a value you set that unlocks your account. It is used on your device to derive the keys below it, and its custody rule is specific: it is never transmitted to any server, and it is never used for anything other than that one derivation step.
Your studio — a workspace — has its own key, sealed to the identity of each of its members.
Each vault — a shared space inside a studio — has its own key, wrapped under that studio’s key.
Each photo or video has its own key: generated once, wrapped under its vault’s current key, and never reused for anything else. Losing that one derived key, on its own, exposes only that photo — it does not limit what someone holding the vault’s own key can already read, which is the whole point of sharing a vault.
The original file, and each version PhotoLog generates from it — a thumbnail, a preview — are each encrypted with their own key, derived from that photo’s key.

Every wrapped key and every encrypted photo in this hierarchy is versioned. Removing someone from a vault rotates its keys, so photos added afterwards are protected by keys they never had — on a device that has already seen the rotation.

That last clause is the honest limit, and it is worth stating plainly. A device seeing a vault for the first time — a new phone, a fresh install, a cleared browser profile — has no history to compare against, so it accepts the version PhotoLog’s servers hand it. That is the same first-use trust every device places in the first key it is ever shown, and versioning does not remove it.

What PhotoLog can still see

Photo and video contents are encrypted before they reach PhotoLog. The facts around them are not: PhotoLog’s servers see a file’s size and when it was uploaded, which studio and vault an item belongs to, who is a member of a studio, and when a share link is used. That is ordinary operational information — the kind any hosted storage service sees about what it stores and serves — not a claim about content.

Stating this plainly matters because “your photos are encrypted” is a claim about file contents, not a claim that PhotoLog holds nothing at all about your account, your studios, or your activity. Both are true, and they are different claims.

When you share a link or QR code to specific photos, the key that unlocks them travels only inside that link — in the part of the web address that browsers do not send to any server — never through PhotoLog’s own systems.

A share link works like a key: whoever holds it can use it, so send it only over channels you trust. Revoking it stops future use, but it does not undo what someone already saw or saved with it before you revoked it. If a link is compromised, the fix is a new one — a compromised link is replaced, not repaired.

If you lose your account secret

There are three ways back into your account:

A Recovery Code, generated once and shown to you when you create your account, which you record and keep somewhere safe outside PhotoLog.
Another device where you are already signed in.
Help from another member of a studio you belong to. They can restore your access to the vaults you share with them.

Member-assisted recovery restores your access to vaults you share with the members who help you; it does not restore your account, your account secret, or anything your helpers never held.

If you are the only member of a studio, and you lose both your Recovery Code and every device that is still signed in, that studio’s content cannot be recovered — not by you, and not by PhotoLog. PhotoLog holds no separate copy of those keys, no administrative override exists, and no support process can bring that content back. This is why PhotoLog asks every new account to record a Recovery Code before setup can finish, and why a studio with only one member is told, at creation, that this is its situation.

PhotoLog staff cannot recover your encrypted photos if your account secret and every recovery path are lost. Record your Recovery Code somewhere safe, and consider keeping a second device signed in or inviting someone you trust into your studio — either gives you a second way back in.

Older galleries, and what happens to them

PhotoLog also has galleries created before this system existed. Those older galleries are locked with a shared passphrase, not per-user encryption, and we are replacing them.

What this page does not claim

Not an unqualified claim that nobody but you can ever open your account. Someone who could serve a modified copy of PhotoLog’s own application to one specific device would see whatever that copy can see — including your account secret as you type it — because encryption and decryption run inside the application’s own code, wherever that code is actually running. Today’s web application has no mechanism that would let your device prove to you it is running the genuine, unmodified version, the way a signed and independently verifiable build would. This is a real limit and it is stated here rather than left for a technically sophisticated reader to discover on their own.
Not a claim that the separation between your login and your account secret has been proven. PhotoLog’s login service receives whatever you type at every sign-in. Whether the value you use to unlock your encryption keys is ever the same value is an assumption this project has ruled on but cannot itself enforce or verify — it is owned by the identity provider PhotoLog relies on. This page describes a feature — where encryption happens, and what does and doesn’t get sent as part of it — rather than a guarantee about what an operator could or couldn’t do with your keys.
Not a claim that a browser extension, a compromised device, or a bad script running inside PhotoLog’s own app is defended against. Anything running where your account is already unlocked sees what that session sees, and can act with that session’s authority, including creating a share link and keeping the key it carries.
Not a claim that PhotoLog’s encryption design has been independently audited or reviewed. No outside security firm has reviewed it, and none is currently planned. What exists is a design written and reviewed inside PhotoLog, differential testing against other independent implementations of the same published constructions, and a written internal adversarial review — all of it internal, and none of it a substitute for outside audit.
Not a claim about storage volume. PhotoLog’s plans are metered, not unbounded — see pricing for current plan limits.
Not a claim that your files can never be lost or made unreachable. Encryption protects what is inside a file from being read; it says nothing about availability. Keep your own backups of anything irreplaceable.
Not a claim that a storage vendor performs the encryption. Any account that names a storage provider as the party doing the encrypting describes a different architecture from PhotoLog’s — see “Where encryption happens,” above.
Not a claim about reviewing what studio members or contributors upload. PhotoLog does not moderate uploads today — no automated review and no human review of what is stored privately. That is a statement about what PhotoLog does, and it is checkable: no moderation code exists in any PhotoLog repository, re-verified 2026-08-28.

How we verified this

Every statement above was checked against PhotoLog's own source and documentation on the date shown. Where the source did not settle a question, the page says so rather than filling the gap.

Uploads are presigned direct-to-object-storage, and the server never sees plaintext, a key or a ciphertext body (verified 2026-08-28)
The key hierarchy PhotoLog's encryption is built on: an account secret, an identity keypair, a per-studio key, a per-vault key, a per-item key, and per-representation stream keys, with custody relations as specified (verified 2026-08-29)
The account secret's custody: never transmitted to any server, and never used as an input to any operation other than the one that derives your keys from it (verified 2026-08-28)
Whether the value used to unlock encryption keys is ever the same value used to sign in is not something this repository can enforce or verify; it is an assumption owned by the identity provider, not a demonstrated property (verified 2026-08-28)
Each studio has its own key sealed to its members; each vault inside a studio has its own key wrapped under the studio's key; each photo or video has its own key, generated once and never reused, wrapped under its vault's current key (verified 2026-08-28)
What PhotoLog's servers store and can see per studio, vault and item, versus what they never hold, such as any studio, vault or item key (verified 2026-08-28)
PhotoLog's servers see operational facts about a file, such as size and upload timing, in the ordinary course of running the service, even though the file's contents are encrypted (verified 2026-09-01)
A share link's key travels only inside the link, in the part of the address browsers do not send to any server (verified 2026-08-28)
Revoking a share link stops future use of it, and does not undo what a holder already saw or saved with it beforehand (verified 2026-09-01)
The three recovery paths for a lost account secret — a Recovery Code recorded at account creation, another signed-in device, or help from another member of a shared studio — and what each restores (verified 2026-08-28)
Member-assisted recovery restores access to vaults shared with the members who help; it does not restore the account, the account secret, or anything the helpers never held (verified 2026-09-01)
A sole member of a studio who loses their Recovery Code and every signed-in device has no way to recover that studio's content; PhotoLog holds no escrow, no administrative override exists, and support cannot restore it (verified 2026-08-28)
What support can and cannot do around an account secret and stored keys — support holds no key material and cannot reset, restore, or bypass an account secret (verified 2026-08-28)
Older galleries created before this system are locked with a shared passphrase, not per-user encryption, and are being replaced (verified 2026-09-01)
An operator able to serve a modified copy of PhotoLog's application to one specific device would see whatever that copy can see, including an account secret as it is typed, because encryption and decryption run inside the application's own code; today's web application has no mechanism proving to a user it is running the unmodified version (verified 2026-09-01)
No outside security firm has reviewed PhotoLog's encryption design or its implementation, no independent audit exists, and none is currently planned (verified 2026-09-01)

How PhotoLog encrypts your photos