File Metadata Analyzer

Read the metadata hidden inside photos, PDFs, Office documents and audio files

Drop files onto this tool and it reads what is embedded inside them but not shown to you when you open them: the camera and GPS coordinates written into a photo, the author and producing software recorded in a PDF, the creator and company name stored in a Word or Excel file, the ID3 tags in an audio file. You can queue several files at once and export the whole set as CSV.

Nothing is uploaded. The tool makes no network requests of any kind — there is no upload endpoint and no server involved. Files are read through the browser's File API, parsed in the page, and discarded when you close the tab. This is verifiable rather than a promise: open your browser's network panel and analyse a file, and you will see no request go out. It matters here more than for most tools, because the entire point is to inspect documents whose metadata you would not want to hand to a third party.

What it reads, by format

Two toggles control the expensive work. EXIF extraction can be switched off if you only want basic file facts. SHA-256 hashing is on by default and computed with the browser's Web Crypto implementation; it is skipped automatically for files of 100 MB or more, since hashing those in a browser tab is slow and rarely what you wanted.

EXIF, and the GPS problem

EXIF is the block of metadata a camera writes into an image at capture time. Some of it is genuinely useful — the exposure triangle, the lens, the exact capture timestamp. The tool decodes the numeric fields into readable values rather than showing you raw codes: exposure time as a fraction, flash as a description of whether it fired and whether the strobe returned, plus metering mode, exposure program, white balance and colour space.

Then there is the location data, and it deserves its own treatment because it is the one metadata field that has repeatedly caused real harm.

A phone with location services enabled for the camera writes latitude, longitude and often altitude into every photo, accurate to a few metres. The photo looks identical with or without it. When present, this tool renders the coordinates in degrees-minutes-seconds and offers a map link, which is the fastest way to understand what a coordinate pair actually discloses — it is one thing to see a number, another to see the pin land on a house.

The practical exposures:

• Photos of items for sale. Marketplace listings photographed at home publish the seller's address to anyone who downloads the image, unless the platform strips metadata.
• Photos of children. Pictures taken at a school, a home, or a regular activity encode where that place is.
• Anything from a person whose location is sensitive — someone fleeing an abusive situation, a journalist protecting a source, staff at a facility that gets targeted.
• Corporate images. Photos from inside an office or a site, published in a blog post or a deck, tagged with the coordinates of a facility that is not on any map.
• Timestamps. Even without GPS, capture times across a set of photos reconstruct a movement pattern.

Most large social platforms strip EXIF on upload. Do not rely on it: coverage varies by platform, by upload path, and by whether the image was sent as a file attachment rather than through the image pipeline. Sending a photo as an email attachment, a chat file, or a download link preserves everything. The check is thirty seconds — drop the file here before you publish it.

EXIF also carries fields that are not location but still identify: Software often names the exact editing application and version, Artist and Copyright may hold a real name, and ImageDescription sometimes contains notes the photographer never meant to ship. The IPTC and XMP blocks, which the extraction also reads, are where editing tools store captions, keywords, creator contact details and rights statements.

Documents: author, company, revision count, and the software trail

Office and PDF files carry a comparable set of identifiers, and they leak in a different way — through documents that get emailed, published as PDFs, or posted on a website.

A .docx, .xlsx or .pptx is a ZIP archive. The tool unzips it in memory and reads the two properties files inside the package. From docProps/core.xml you get the creator, the last modified by name, the title, subject, description, keywords, category, the revision number, and the created and modified timestamps. From docProps/app.xml you get the producing application and its version, the company name, the manager field, the template the document was based on, and the content statistics.

Read what that combination discloses about a document sent to a client or published on a website:

• Creator and last-modified-by are usually real names, pulled from whoever's Office installation touched the file. A proposal that went through three people carries the last one's name, and the creator field frequently still names the person whose old document was reused as the starting point.
• The company field is set from the Office installation. A document sent from your firm but authored at a previous employer, or by a contractor, says so.
• The template name reveals which of your internal templates — and sometimes which client's template — the document descends from.
• The revision number is the save count. It will not reconstruct an edit history, but a single-digit count on a document presented as extensively reviewed tells its own story, and so does a very high one.
• Created versus modified timestamps establish when work actually happened, which is often the point in a dispute.

PDFs are read differently — the tool scans the file structure for the header version, the presence of an encryption dictionary, an approximate page count, and the document information dictionary. The Producer field is the most informative in practice: it names the exact software and version that generated the PDF, which frequently reveals the original authoring tool, the operating system, and sometimes the specific product build in use on the machine that made it. Creator names the application the content came from. Author is very often a real person's account name that nobody thought to clear.

Two honest caveats on PDFs. The page count is derived by counting page-object markers in the file, which is reliable for ordinary documents but can be off for PDFs that store their structure in compressed object streams. And a PDF flagged as encrypted may keep its information dictionary out of reach entirely — an empty result there is not proof that no metadata exists. The Office reader targets the OOXML package layout used by .docx, .xlsx and .pptx; OpenDocument files store their properties elsewhere in the archive and will generally come back without document properties.

Stripping metadata before you publish

This tool reads metadata; it does not remove it. Removal is a separate operation, and it is worth knowing how to do it properly rather than trusting that a platform will handle it.

The reliable workflow is: strip, then re-check here to confirm the fields are actually gone. Verification is the step people skip, and it is the one that catches a tool that cleared EXIF but left XMP behind.

• Windows. Right-click the file, Properties, Details tab, "Remove Properties and Personal Information". It will offer to create a cleaned copy. Works on images and Office documents.
• macOS. Preview can remove image location data via the inspector. For anything systematic, use the command line.
• iOS and Android. Both offer to remove location when sharing an image — iOS behind "Options" in the share sheet, Android in the share dialog for photos. Both are per-share and easy to forget; turning off location access for the camera app is the durable fix.
• Command line. exiftool -all= image.jpg removes all metadata; exiftool -gps:all= image.jpg removes only location while keeping the exposure data a photographer wants. For a whole directory, exiftool -all= -overwrite_original *.jpg.
• Office. File → Info → Check for Issues → Inspect Document, then remove document properties and personal information. Note that this also finds comments, tracked changes and hidden rows, which metadata inspection alone will not show you.
• PDF. Metadata survives most PDF workflows and often gets added by them. Check exported PDFs specifically — a Word file you cleaned can produce a PDF that reintroduces your name through the producer and author fields.
• A crude but effective fallback for images: screenshot it, or re-encode it. A screenshot carries none of the original EXIF. You lose quality, and you gain certainty.

One thing stripping does not fix: content that is visually present. Redaction by drawing a black box over text in a PDF leaves the text in the file. That is a document-content problem, not a metadata problem, and no metadata tool will catch it.

Metadata as evidence

The same fields that are a privacy liability are evidence when you are the one investigating. The common uses:

• Establishing when something was actually created. A document dated in its text can be checked against its embedded creation timestamp and its save count. Filesystem dates are trivially altered; embedded properties are less commonly thought of.
• Attributing authorship. Creator, last-modified-by, company and template fields link a document to a person and an organisation. A supposedly independent document produced from an interested party's template is a finding on its own.
• Verifying that an image is what it claims to be. A photo presented as taken at a place and time either carries a consistent capture timestamp, camera model and coordinates, or it does not. Absent EXIF is not proof of tampering — most platforms strip it — but EXIF that contradicts the claim is significant, as is a Software field naming an image editor.
• Building a timeline across a file set. Load a batch and export the CSV. Capture timestamps and modification dates across dozens of files reconstruct a sequence far faster than opening each one.
• Identifying the source device. Camera make, model, lens and serial-adjacent fields tie a set of images to one device.
• Integrity. The SHA-256 hash gives each file a fingerprint you can record and re-verify later, so you can demonstrate that the file you analysed is the file you were given.

Two cautions if this is going anywhere consequential. Metadata is trivially editable — anyone with exiftool can set any field to any value — so treat it as corroborating rather than conclusive. And in a formal investigation, work from a copy with the hash recorded and use tooling appropriate to the process; a browser tool is right for triage and for understanding what a file contains, not for producing a chain-of-custody record.

Practical notes

• Files are processed one at a time with a progress indicator, so a large batch is slow but predictable. Everything competes for one browser tab's memory — very large files, particularly with hashing on, will be the slow part.
• The image preview is drawn from the file onto a canvas in the page. It is not fetched from anywhere.
• A file with no findings is a real answer. Screenshots, images that have been through a stripping pipeline, and PDFs from generators that write no information dictionary genuinely have nothing to show.
• The CSV export contains one row per file with the file basics, image dimensions, the main EXIF fields, GPS coordinates as decimals, the PDF information fields and the audio tags — the format to use when you are comparing many files rather than reading one.