Create a separate publication copy, remove metadata you do not intend to disclose, inspect the actual downloadable original and generated versions, and review visible clues separately from embedded data.
A photograph can reveal more than the scene in its pixels. Depending on the camera and settings, the file may contain location or other metadata. Uploading it to a website introduces another question: which version can a visitor download, and what information remains in that version?
Do not assume that a small thumbnail or a compressed format has removed everything sensitive. Create a publication copy deliberately, inspect it and then verify the files the live site actually serves. Treat visible details in the photograph as a separate review; removing coordinates cannot hide a street sign in the frame.
Separate file metadata from visible information
Metadata is information stored with the file rather than shown as the main picture. Depending on the file, device and editing history, it may include capture details, camera information, credit, captions or location. Fields can appear in different metadata systems, so checking only one location field is a narrow review.
Apple’s personal safety guide explains that location can accompany photos and describes supported controls for reviewing or excluding it. A particular sharing setting is useful evidence about that workflow, not a general promise that every file exported elsewhere is clean.
Review the picture itself too. Faces, addresses, reflections, badges, screens and recognizable landmarks can disclose information without any metadata. A filename such as a customer’s full name and address can also defeat an otherwise careful cleanup.
Decide what must remain private before processing
Consider a fictional maker publishing photographs of a home workshop. The useful public information is the workbench and finished item. The exact home coordinates, private notes and customer names are unnecessary. The maker also needs to preserve a photographer’s required credit without exposing unrelated personal details.
Write down the intended public content and the fields that need review. Keep the untouched source in private storage with appropriate access. This provides recovery if an export damages quality and preserves licensing evidence. A private original means a file kept out of public website storage, not merely an attachment removed from the navigation menu.
Create a separate working copy for publication. Use a neutral, descriptive filename and avoid putting private details into its caption, alternative text or attachment description. Those text fields are separate from embedded image metadata and need their own review.
Use a deliberate removal and inspection workflow
- Inspect the working file with a tool that reports the relevant metadata, not just the small summary shown by one photo viewer.
- Use the export or removal controls appropriate to that tool to exclude information you do not intend to publish.
- Save the result as a separate publication file, then inspect that saved file again.
- Check appearance, orientation, dimensions and color. Privacy processing must not silently make the published image incorrect.
- Record the file reviewed and the remaining intentional metadata before uploading it.
Keep the check specific. “The export did not contain location in the inspected fields” is more meaningful than “the photo is anonymous.” An image may have other fields, and a viewer may not display all of them. Choose an inspection tool and scope appropriate to the sensitivity of the material.
Do not strip everything mechanically without checking the result. Some embedded information supports correct rendering or legitimate attribution. The goal is a reviewed publication copy, while any required visible credit remains on the page and the private permission record remains separate.
Understand why a resized WordPress image is not the whole answer
WordPress has image-processing behavior that may remove metadata from generated files. The image_strip_meta reference documents its metadata-stripping filter. Different editors, plugins and processing paths can affect what actually happens on a site.
Even when a resized image has been cleaned, the original upload may be a different file. WordPress provides a function to obtain the original image URL when an original exists separately from a processed image. Seeing a clean small version on the page therefore does not establish that every reachable version is clean.
WordPress can also read information from the uploaded image: wp_read_image_metadata documents that metadata-reading workflow. Do not infer that all those fields are publicly visible. Instead, inspect the attachment fields, templates and any custom output that your own site exposes.
Inspect the actual files a visitor can receive
After uploading a sanitized copy, open the published page as an ordinary visitor. Identify its displayed image and any links to a larger version or attachment page. Review the original upload address and the generated sizes that your publication workflow makes available.
Download those public files for inspection. Keep track of which file is which; a clean screenshot of the page is not a metadata test of the original photograph. Compare file properties and the intended cleanup rather than relying on the displayed dimensions alone.
If a CDN or image service transforms the image, include its served output in the check. The responsive-image guide explains why the browser may choose a different file from the one you first expect. The underlying original deserves a separate check even when the browser selects a small derivative.
Use a small publication acceptance sheet
| Surface | Check | Evidence to retain |
|---|---|---|
| Publication copy | Unwanted metadata removed and appearance preserved | Reviewed file identity and inspection result |
| Visible scene | No unintended address, face, screen or identifying detail | Human review of the finished crop |
| Original route | The publicly available upload is the sanitized copy | Address and downloaded-file inspection |
| Generated versions | Relevant resized and transformed files reviewed | Version list and result for each |
| Page text | Filename, caption, credit and alternative text are appropriate | Ordinary-visitor page check |
For the fictional workshop, the acceptance record might say that coordinates were absent in the inspected publication files and the visible frame no longer included the house number. It should also state which versions were checked. This is a bounded observation, not a promise that nobody can identify the location.
Recover carefully after an unintended upload
If a sensitive original was published, first identify its public addresses and derivative copies. Remove or replace the unintended files through the site’s supported workflow, update the page references and inspect the CDN or cache behavior. Uploading a clean replacement does not itself prove the previous address stopped serving the old file.
Review access as an ordinary visitor after the change. Copies already downloaded or retained elsewhere may remain outside your control. Where the disclosure is consequential, handle it as an actual information exposure rather than treating an updated thumbnail as complete recovery.
Then fix the repeatable process. Use the Media Library sizing workflow after the privacy review, and check the complete format journey if you change image formats. Repeat the file inspection when the editor, plugin or transformation service changes.
Finally, review capture and sharing settings for future photographs. Cleaning one existing upload does not establish that the next photograph will follow the same safe path. Keep the private original, the publication copy and the live-file check as distinct steps.
Sources and verification
Editorial review 2026-10-15. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- Apple Personal Safety User Guide: Manage location metadata in PhotosChecked Location can accompany photographs; Apple documents reviewing location information and controlling its inclusion in supported sharing workflows.
Limits: These controls concern supported Apple workflows and location information, not a guarantee that every metadata field or visual identifying clue is removed. - WordPress Developer Resources: image_strip_metaChecked WordPress exposes an image metadata stripping filter used in image processing; behavior of resized outputs is not evidence about every uploaded original.
Limits: The actual image editor, plugins and pipeline can differ, and the hook does not certify the privacy of a particular publicly available file. - WordPress Developer Resources: wp_get_original_image_urlChecked WordPress can retain a distinct original image address when using a processed image, so reviewing only the displayed version is insufficient.
Limits: The function identifies an original URL; access controls and actual exposure depend on the site configuration. - WordPress Developer Resources: wp_read_image_metadataChecked WordPress can read image metadata including credit, camera and creation-related information into its processing workflow.
Limits: Reading metadata does not mean every field is publicly rendered; publication surfaces must be inspected rather than assumed.