The attachment name is another layer

Photo Filename Privacy: Rename the Sharing Copy

A photo filename can disclose a person, address, case, or project even when the picture and supported metadata have been reviewed. Rename the exact sharing copy to a neutral name, preserve its real extension, and inspect the attachment preview. Renaming is not metadata removal, pixel redaction, or a promise that a sharing service hides the name.

By Qingxin Studio, the developer of HushPic · Updated

Read the name as part of the message

Look for names, addresses, customer or ticket identifiers, workplace projects, and dates you did not intend to disclose. The fictional name client-alex-home-address.jpg says more than image-01.jpg even if the files contain identical pixels.

Email, document attachments, download links, and image-sharing modes can present names differently. You do not need to prove how every service behaves to avoid deliberately putting a private identifier in the file you send. Inspect the actual interface rather than assuming the name is invisible.

Rename only the prepared copy

Identify the current image you have reviewed, keeping originals and earlier exports separate. On Mac, select the sharing file in Finder and use Rename. Use your device’s file manager for the equivalent operation elsewhere; this website does not rename selected photos.

Choose a neutral name such as image-01.jpg or issue-view-02.png, retaining the existing extension. Do not change HEIC to JPG to disguise the format. Apple warns that changing an extension can prevent an app from opening a file; a different suffix does not convert its contents.

Do not replace one identifier with another

A case number, initials, exact timestamp, or internal project code can still be private in context. Describe the image’s useful role rather than the subject’s identity. For a screenshot set, neutral sequential numbers communicate order without repeating a participant’s name.

If a verified private support channel requires a reference, follow its instructions. Do not reuse that identifying filename for a public post. A public copy and private evidence attachment may have different names and disclosure requirements.

Reopen and check the selected attachment

Open the renamed image to confirm it is the prepared output. In the sending interface, inspect the selected attachment and any displayed name. Remove accidentally selected originals or duplicates that restore a hidden detail.

If you export again, check the new name: an editor may choose another default. Review archive names, captions, and link labels you create. Renaming locally cannot change a previously received copy or remove a name you typed in the message.

Keep the other privacy layers independent

Renaming does not clean EXIF, XMP, IPTC, or other embedded information. Check supported hidden categories in the actual attachment with the read-only browser tool, and review visible names, addresses, faces, and codes independently. A neutral name is not a clean metadata result.

HushPic processes supported photos on iPhone and Android locally into separate checked copies, with suggestions that may miss details. Review the result and regenerate after adjustments. This page does not claim that HushPic guarantees a neutral filename for every receiving service or makes an image anonymous.

Sources

This guide is published by Qingxin Studio, the developer of HushPic. Product claims describe our supported workflow, not independent certification. Our review checklists are practical first-party guidance; linked platform sources support only the mechanisms they describe. Automatic checks may miss details. Read our content and corrections policy.

Privacy guides

Continue the privacy check.

View all guides