· Updated
Find Exposed Metadata in Website Documents and Images
Check linked PDFs, Office files, and images for hidden metadata that may reveal author names, file paths, reviewer comments, or GPS coordinates.
Want to know what's broken on a site you manage?
Run the free check →On this page (6 sections)
A client may approve a PDF brochure or an image for publication without realizing the file also contains an author name, an internal file path, or a photo’s GPS coordinates. Those details can be visible to anyone who downloads the file. A metadata check helps an agency find information the client may not have intended to publish.
Not every metadata field is sensitive: a copyright notice or the name of the software used to create a PDF may be intentional. Review each finding with the file’s owner before deciding what to remove.
What can a website metadata check find?
The checks depend on the file type and which fields are present:
| File type | Examples worth reviewing |
|---|---|
| Author, creator and producer fields; email addresses or internal paths in selected metadata fields | |
| Word, Excel and PowerPoint files | Author, last editor, company, manager or template path; supported reviewer-comment parts |
| Word documents | Tracked insertions and deletions |
| Linked images | GPS coordinates, creator, device or software details, when present in supported metadata |
SitesRadar looks at supported PDF, DOCX, XLSX, PPTX and image files linked from pages it crawls. It checks selected metadata and supported comment or tracked-change markers; it does not read every possible field, search all document contents for secrets, or remove information from the original file. Image checks apply to supported files discovered as links, not necessarily every image embedded in a page.
Check files already linked from a site
Run the free website checker with the client’s domain. Alongside other website checks, it can inspect supported, same-site files linked from the pages it discovers and report selected metadata that may deserve review. You do not need to upload a private document to the checker.
The free check crawls up to 10 pages and checks up to 25 discovered files, with a 15 MB limit per file. Links outside the crawled pages, external files, unsupported formats, larger files, and encrypted or unreadable files can be missed or skipped. A clean result is not proof that a whole site or every document is free of sensitive information. Use a separate file-level review for important files and parts of the site outside that scope.
Scheduled monitoring can repeat this check for monitored sites. It is useful for spotting changes in the files the crawler reaches, but it has its own crawl and file limits and is not a complete inventory. See the plans for monitoring options.
Example: a PDF with an internal file path
In a local test of SitesRadar’s metadata scanner, we created a synthetic PDF with an author of j.smith and a creator field containing C:\Users\jsmith\report.docx. The scanner identified the author and the internal path as separate findings. These values are test data, not information from a client site.
If a public brochure had a similar finding, the agency could ask its owner whether the author and path were meant to be public, inspect a copy of the source document, remove unwanted properties using the appropriate application, and replace the published file. Then inspect the replacement again. A path or author name alone does not prove an account was compromised, and a clean scan does not rule out other sensitive information.
This example exercises the metadata scanner with a PDF linked from a locally simulated crawl; it is not a screenshot or a claim that a live website was scanned. SitesRadar reports selected fields and does not edit the file itself.
What should an agency do with a finding?
- Open the public file and confirm the context. Determine whether the value is actually sensitive and who owns the document or image.
- Review the source file. In Office, inspect document properties, comments, and tracked changes; for images, review location and other embedded metadata. Some fields, such as author or copyright, may be deliberately published.
- Create a clean copy using the appropriate application. Removing metadata or accepting changes can alter a document, so preserve the original and get approval when needed.
- Replace the published file and verify it. Check the public URL, caches, and links, then inspect the replacement with an appropriate file-level tool. A site scan is a useful follow-up, but its coverage limits still apply.
- Fix the publishing process. Add a review step to export and upload procedures so the same information does not return with the next revision.
Microsoft documents how to inspect Office files for hidden data and personal information. Its document inspector is one option for reviewing individual files before publication.
How is this different from a PDF metadata viewer?
A PDF metadata viewer typically helps you inspect a file you already have. A website check starts with a public site and looks at supported files linked from the pages it crawls. The two approaches work together: use site discovery to find possible exposures, then use a file-level tool to investigate or clean a particular document.
This check concerns metadata inside files, such as a PDF’s author or a photo’s location. It is different from a page’s SEO title and description, which help describe a web page to search engines.
FAQ
Can a PDF reveal an author’s name?
Yes. A PDF may include an author field and other document properties. Whether those details should be public depends on the document and its owner.
Does SitesRadar remove the metadata?
No. It reports selected observations so you can review the source and replace the public file if needed.
Does a clean check mean no files leak information?
No. The crawl and file limits, supported formats, and unreadable files all affect coverage. Review important documents individually as well.
Can images expose location?
Some photos include GPS coordinates in embedded metadata. SitesRadar can report coordinates when it finds them in a supported, linked image it can parse.
Build the check into your broader client-site maintenance checklist, particularly after a redesign, migration, or batch of new uploads.