What the File Audit Lab reads, calculates, and refuses to do

1. Safety boundary

The File Audit Lab is intentionally read-only. A selected folder is represented by browser File objects. The application can inspect metadata and, only when requested, read bytes to calculate a digest. It does not request a writable directory handle, call a deletion API, or overwrite a file. The rename feature produces a proposed path and a downloadable mapping; it does not apply that mapping.

This boundary reduces the damage a bug or an ambiguous rule can cause. It also keeps the final decision with the person who understands the folder. “Duplicate” can mean byte-identical, visually equivalent, obsolete, or merely inconvenient. A generic tool cannot resolve all of those meanings safely.

2. Inventory fields

For each selected file, the page records the relative path supplied by the folder picker, the filename, the parent folder, byte size, browser-provided MIME hint, and last-modified timestamp. The browser does not reveal the full device path. The MIME value can be empty or inaccurate because it is a hint derived from the platform; the extension view is therefore shown separately.

Relative path

Used for grouping, searching, and collision detection. It is the path below the folder you selected, not a global disk path.

Byte size

Used for totals and the first duplicate-candidate screen. Empty files are excluded from candidate groups because many unrelated empty files are expected to have the same size.

Modified time

Useful context, not proof of identity or age. Copying, downloading, or restoring a file can change this value.

MIME hint

Displayed for inspection only. The application does not claim that the MIME hint validates the file format.

3. Duplicate evidence

Stage A: same-size candidates

Two byte-identical files must have the same byte length, so grouping by size is an efficient way to reduce the comparison set. The reverse is not true: two different files can have the same length. For that reason the interface calls these groups candidates, not duplicates.

Stage B: SHA-256 verification

When you select verification, each candidate file is read in the browser and passed to the Web Crypto SHA-256 digest function. The process runs sequentially to avoid reading many large files at once. A group is shown as content-confirmed only when at least two files have the same size and the same digest.

A matching cryptographic digest provides extremely strong evidence that the bytes match, but it does not decide which copy is authoritative, whether metadata outside the file differs, or whether deleting a copy is appropriate. The tool therefore calculates potential recoverable bytes but never chooses a file to remove.

4. Rename preview

The default profile performs Unicode NFKC normalization, replaces characters invalid on common desktop filesystems, collapses whitespace to hyphens, collapses repeated hyphens, trims unsafe leading or trailing punctuation, lowercases the result, and preserves the extension. Optional prefix, suffix, sequence, and ASCII-only transformations can be layered on top.

Collision detection compares the entire proposed relative path in a case-insensitive form. That is deliberately conservative: a set of names that is valid on a case-sensitive system can still collide after transfer to a case-insensitive system or cloud sync service. Every member of the collision set is marked; the software does not silently add a suffix because automatic conflict resolution can hide a more important naming problem.

5. Network and privacy behavior

The site itself is delivered over the network, so the hosting provider receives normal requests for HTML, CSS, JavaScript, the demo dataset, and other static assets. Selected local files are not included in those requests by the application. Inventory processing and SHA-256 calculation happen inside the browser process.

The code contains no analytics library, account system, upload endpoint, advertising loader, or remote file-processing API. The public AdSense account metadata is present for ownership verification, but advertisements are not loaded in this pre-approval release. See the privacy notice for the complete scope.

6. Known limitations

• Folder selection through webkitdirectory is widely supported in Chromium-based browsers but remains a non-standard attribute. A browser that does not support it may allow only ordinary file selection.
• The inventory does not inspect EXIF data, archives, embedded documents, image similarity, or media perceptual hashes.
• SHA-256 verification reads candidate bytes; large datasets may take time and consume memory.
• Modification dates and MIME hints can be missing or misleading.
• The rename preview cannot predict every rule imposed by every NAS, sync client, shell, or legacy application.
• Exports are evidence for review, not a backup. Keep an independent backup before any destructive cleanup performed outside this site.

The release tests and exact demonstration expectations are published in the test log.