This page is for people who want to inspect a file's metadata for possible AI manipulation.
File history often matters almost as much as file contents. A document, whether it's an image, PDF, archive, or e-mail, can carry timestamps, software traces, authoring clues, export fingerprints, and format-specific signals that help explain how the file was created, saved, re-saved, forwarded, flattened, or stripped down over time. This page use's your web browser to process a file to a review it's metadata using static code.
About this page and its limits: This is *not* a forensic certification, *not* a formal expert opinion, and *not* a substitute for chain-of-custody handling, source verification, or laboratory-style forensic examination.In addition to being a lawyer, I'm also CompTIA A+, Network+, Security+, and Server+ certified. This tool appears on my law firm's domain because only because computers, technology, networking, and IT are some of my hobbies and I already have web hosting for my law firm. This page was iteratively drafted and revised with LLM assistance, then cross-checked against the actual source code, browser behavior, and the verification mindset reflected in the my recent publications AI Concerns Facing Maryland Lawyers in 2026 and Beyond and Trust but Verify: Cross-Checking LLMs (A Practical Workflow).
This is a work in progress and is being provided for educational and informational, and not legal, purposes only. You are not uploading anything to the Proy Law Firm and no professional representation exists without a formal, written fee agreement.
All parsing and metadata extraction happen locally inside this single HTML file.
When you add a file here, your browser reads it into your computer's memory (RAM) and your device processes it locally with its own CPU. The file is not sent to a server for processing and no results are sent back from a server.
0 files · 0 B total · No file type yet
Local cache: checking browser-private storage support…
Supported file types
This embedded build can open and review the following file types when your browser allows you to select them locally:
- Text and markup: .txt, .md, .markdown, .html, .htm, .xml, .json, .csv, .tsv, .log
- Email and web archive: .eml, .msg, .mht, .mhtml
- PDF: .pdf
- Microsoft Office: .doc, .dot, .docx, .docm, .dotx, .dotm, .xls, .xlt, .xla, .xlsx, .xlsm, .xltx, .xltm, .xlam, .ppt, .pot, .pps, .pptx, .pptm, .ppsx, .ppsm, .potx, .potm, .rtf
- OpenDocument: .odt
- Archives: .zip, .7z, .tar, .gz, .rar
- Images: .jpg, .jpeg, .png, .gif, .webp, .bmp, .tif, .tiff, .svg
This list mirrors the current accept attribute on the file picker in this revision.
About these fields
MIME type is the browser-reported media type for the file, such as application/pdf.
Top-level parser is the first embedded parser route this page used to open the file locally.
Only fields with extractable metadata are shown. Empty or unavailable fields are omitted.
Content Credentials / Provenance reports whether this embedded build found likely C2PA or Content Credentials data, whether that data was readable locally, and any claim-generator, action, ingredient, thumbnail, signer, issuer, or timestamp clues that could be extracted in-browser.
Image details surfaces image-specific metadata like dimensions, camera/device data, capture settings, GPS, IPTC/XMP presence, ICC profile clues, and related technical fields when they are available in the file.
Office details surfaces Word, Excel, and PowerPoint-specific metadata such as comments, notes, hidden content, hyperlinks, macros, embedded objects, templates, revision/edit history clues, and workbook or presentation structure when those fields are present.
PDF details surfaces PDF-specific metadata like version, page count, document IDs, tagged/forms/embed flags, JavaScript presence, annotation counts, and save/export workflow clues when those fields can be extracted locally.
Email details surfaces sender/routing metadata, multipart structure, attachment counts, embedded-message counts, mailer clues, and delivery-chain hints for .eml-style files when those fields can be extracted locally.
Deep parser tier runs an additional fully local metadata pass for supported file types to surface more metadata families, namespace clues, relationship targets, marker strings, and technical signals than the standard parser alone.
Hidden content and external dependencies pulls comments, notes, hidden sheets or slides, tracked-change indicators, macros, embedded objects, attachments, thumbnails, external links, workbook connections, linked templates, and remote references into one review section and explains why each item may matter.
Risk flags, image authenticity clues, office authenticity clues, conflicts, privacy exposure, timeline reconstruction, likely origin workflow, suspicious file analysis, and provenance summaries are local heuristics meant to help spot unusual or possibly doctored files. The verdict panel now summarizes likely file history, strongest supporting evidence, strongest weakening evidence, uncertainty factors, and suggested next steps. These sections are advisory, not definitive.
How this tool was created and what it looks for
This webpage processes files within your webbrowser locally (meaning nothing is uploaded anywhere), inspects the metadata and format structures that are actually present, and then organizes the results into a practical first-pass review of a file's general metadata and whether that metadata indicates possible AI manipulation.
Metadata is just structured descriptive information stored alongside or inside the file's main content. Even this HTML page has metadata headers near the top of its source. They tell a browser or downstream reader what the page is, how it should be described, and what URL it prefers to use:
<meta content="Inspect file metadata, provenance clues, privacy exposure, and format-specific signals locally in your browser without uploading the file." name="description"/>
<meta content="index, follow" name="robots"/>
<link href="https://www.proylaw.com/local-file-metadata-and-provenance-review-tool.html" rel="canonical"/>That is a simple example of the header metadata. An HTML file is simply a text file (you can read the text/source coude by pressing F12 on any webpage) that web browsers process for us.
How local browser-only processing works, why a file picker is necessary, and where the file really goes
This page runs as a self-contained client-side application inside your browser. The page code has already been delivered to your browser as ordinary web content. The only thing the browser still needs from you is permission to let that already-loaded code read a local file from your own device. That is why the page needs a file picker or drag-and-drop step.
So when the page says you are "uploading" a file, you are really granting this browser tab local access to a file object through the browser's file APIs. The bytes are then read locally by your browser and processed on your device. In practical terms, the browser is acting as the application layer, just as installed desktop software would. The difference is that the browser is the runtime platform instead of a separate installable program.
function stageIncomingFiles(fileList){
const incoming = Array.from(fileList || []);
...
showBanner('info', 'Local metadata parsing started automatically. Files are preflighted, queued, and processed one at a time in your browser. ...');
addedRecords.forEach(item => enqueue(async () => scanTopLevelFile(item)));
}The optional cache is local too. Instead of calling a remote service, this page uses browser-private storage on your device when supported: OPFS first, then IndexedDB, and otherwise only in-memory session state.
if (navigator.storage && navigator.storage.getDirectory){
const root = await withTimeout(navigator.storage.getDirectory(), 1200, null);
...
}
...
const req = indexedDB.open('fileMetadataScannerCache', 1);In other words, the file is being handed to your browser tab, then read by browser-managed code and browser-managed memory on your own device. There is no need for a server merely to open the file locally, so no server upload route is used here.
- The current source contains no fetch( upload call, no XMLHttpRequest upload path, no FormData upload construction, no navigator.sendBeacon transfer, and no HTML form with an action= endpoint for file submission.
- If this page were transmitting files to a server, you would ordinarily expect to see a URL or endpoint tied to a network request, such as a form post or a JavaScript upload call that explicitly sends the file to a remote path.
const formData = new FormData();
formData.append('file', file);
await fetch('/upload', {
method: 'POST',
body: formData
});A browser cannot inspect a file you have not chosen to expose to it. The picker or drag-and-drop step is simply the browser-security gate that gives this page local read access to that specific file. After that, the parsing still happens on-device.
Results
Only fields with extractable metadata are shown. Empty or unavailable metadata fields are omitted.