How to Share Photos Securely

None of these services are inherently insecure—they simply optimise for convenience and long-term access. That’s ideal for everyday photos, but not for documents that may still be sensitive years from now. The same retention problem shows up when people send documents by email or paste secrets into chat.

A photo can reveal far more than what’s visible on the screen.

Many phones can embed metadata such as EXIF fields inside an image. Depending on the device, format, and settings, this may include GPS coordinates, capture time, orientation, and camera details. A passport photographed at home could reveal a location; a medical document photographed at a clinic could reveal where it was captured.

Encryption alone does not remove that metadata—it only scrambles the file as-is. If GPS is still inside the plaintext, GPS is still inside the ciphertext until someone decrypts it.

PrivateNote handles common embedded metadata in the product: for JPEG, PNG, WebP, and iPhone HEIC/HEIF attachments, Remove location & photo metadata is available and on by default. Your browser decodes and re-encodes the pixels locally before encryption, which drops common metadata fields such as GPS, timestamps, and camera details. HEIC/HEIF becomes JPEG; JPEG and WebP may be recompressed. If conversion fails, PrivateNote stops the upload. To send the exact original, you must deliberately turn metadata removal off and submit again; the original is still encrypted before upload.

Re-encoding is not a forensic-anonymisation guarantee. It cannot remove an address printed in the image, a face in the background, a barcode, a reflection, or a landmark from which someone can infer location. Review the visible pixels separately. Turn metadata removal off when exact original bytes, original quality, or evidentiary integrity must be preserved.

Client-side encryption still matters next: once the cleaned file is encrypted in the browser, the service stores ciphertext rather than a readable photo. That is the model behind encrypted vs “secure” file sharing.

Rule of thumb

If you would not publish the photo’s location and timestamp on a public map, leave PrivateNote’s metadata toggle on (or strip EXIF yourself) before you encrypt and send.

Good security starts before you press Send.

Take a moment to look at the image itself. Does the recipient need the entire document, or would a cropped version be enough? Removing background details, obscuring unrelated personal information, or blurring irrelevant faces reduces exposure. Keep an appropriate original where records, evidence, or future use require it; remove only unnecessary working copies.

Next, clear hidden location data. On PrivateNote that step is built in for common photo formats—leave the metadata toggle on when you attach the file.

Then encrypt before the photo leaves your device. Client-side encryption transforms the image into unreadable ciphertext locally, so the storage server never receives the original file. Even if the server were compromised, the encrypted data would remain unintelligible without the decryption key.

PrivateNote’s secure file transfer combines those steps: optional in-browser re-encoding for JPEG/PNG/WebP/HEIC, encryption before upload, ciphertext-only storage, a note read limit, and a timed attachment-download window. Recipients can open the link without creating an account; sending a file requires a free PrivateNote account.

Finally, treat service access as temporary. Opening a read-once PrivateNote consumes the note read, but its attachment remains downloadable during the configured post-open window: 15 minutes by default, with eligible plans offering 30 minutes or 1 hour. The recipient may download more than once during that window. Expiration then removes access through PrivateNote; it does not delete copies already saved on the recipient’s device.

Treat the complete PrivateNote URL as a bearer secret. It normally contains decryption-key material in the URL fragment, so anyone who obtains the full link before it expires may be able to open the handoff. If you add a passphrase, send it through a different channel. Sending the link and passphrase in the same thread collapses the two layers into one—see how to share a password securely.

For passports, medical images, financial records, or evidence, first confirm that the organisation accepts this delivery method. A government agency, bank, insurer, or healthcare provider may require its own authenticated upload portal or retention process.

• ✓Verify the recipient and channel
• ✓Crop or blur anything the recipient does not need
• ✓Leave PrivateNote’s “Remove location & photo metadata” on for JPEG/PNG/WebP/HEIC
• ✓Encrypt in the browser before upload
• ✓Set a short note expiry and attachment access window
• ✓Treat the complete URL like the sensitive file
• ✓Share any passphrase on a separate channel
• ✓Remove unnecessary working copies—not an original you are required to retain

This workflow helps when the main risks are forgotten inbox attachments, long-lived cloud links, readable server-side storage, and common embedded photo metadata. Browser-side encryption means PrivateNote receives encrypted file data rather than the readable image, and expiration limits how long that encrypted handoff remains retrievable.

It does not protect against malware or a compromised browser on either device, a malicious or mistaken recipient, exposure of the complete link before expiry, or a recipient saving the decrypted image. Because the web application performs encryption, the code delivered to your browser is also part of the trust model. Use a managed or otherwise trusted device for high-sensitivity documents.

The most common mistakes are surprisingly ordinary. People often leave location data embedded in photos taken at home, assume the recipient will remember to delete the file, or keep permanent cloud-sharing links active long after the exchange is finished. Another frequent error is sending both the encrypted link and its passphrase in the same message, giving an attacker everything they need if that conversation is ever compromised.

It’s also worth remembering that no sharing method can prevent a recipient from taking a screenshot or saving the image after opening it. Secure sharing reduces unnecessary copies and limits long-term exposure, but it cannot control what someone does once they have legitimate access.

• Leaving GPS on for home, school, or clinic photos (or turning PrivateNote’s strip toggle off without a reason)
• Sending the passphrase in the same thread as the link
• Using a permanent Drive or Photos link “because it’s easier”
• Assuming the recipient will delete the download
• Sending the full frame when a crop would do

When sharing sensitive photos, the goal isn’t simply to encrypt the connection—it’s to minimise how many copies exist and how long they survive.

Cropping unnecessary details, re-encoding supported images to remove common metadata, encrypting before upload, and setting short access windows reduce long-term exposure. They do not guarantee that no trace remains: the recipient can retain the decrypted image, and the complete delivery link must itself be protected.

The same approach works for sensitive documents of any kind—not only photos.