Same size is a filter, not a verdict
Byte-identical files always have the same size. That makes size an efficient first screen: instead of hashing every file in a folder, the application can focus on groups that could possibly match. The logical implication works in only one direction. Different files can also have the same size, especially generated media, fixed-length records, templates, and small text files.
The built-in demonstration makes this failure visible. It contains 20 same-size groups. Only 12 have matching synthetic SHA-256 values; 8 groups have different content fingerprints despite identical byte lengths. A tool that labels all 20 groups “duplicates” would be wrong in forty percent of the candidate groups.
What SHA-256 adds
SHA-256 maps file bytes to a fixed-length digest. In the workbench, the browser reads a candidate file and calculates the digest locally with Web Crypto. Two records are shown as confirmed only when both byte size and digest match.
This is much stronger evidence than name, date, extension, or thumbnail similarity. It is still evidence about bytes, not about business meaning. Two identical files can both be required because an application expects each path. Conversely, two images can look identical while containing different metadata and therefore produce different hashes.
A practical three-level model
| Level | Signal | Safe conclusion |
|---|---|---|
| Candidate | Same non-zero byte size | Worth comparing; no deletion conclusion |
| Content-confirmed | Same size and matching SHA-256 | Bytes are overwhelmingly likely to match; path decision remains |
| Deletion-approved | Confirmed bytes plus backup, ownership rule, and human review | One copy may be removed by a separate process |
Why the app hashes sequentially
Hashing every candidate in parallel can allocate several large buffers at once and make a browser tab unresponsive. The release therefore reads one file, calculates one digest, records the result, and moves to the next. This is slower than maximum parallelism but easier to reason about on ordinary laptops and phones.
Files above 256 MB are skipped unless you opt in. The threshold is not a claim that 256 MB is universally safe or that 257 MB is unsafe. It is a conservative default that makes a potentially expensive operation explicit. Device memory, browser implementation, other open tabs, and file count all matter.
How to choose the retained copy
After confirmation, choose a retention rule that uses context rather than file metadata alone. Good rules include keeping the copy in the canonical project directory, keeping the copy referenced by the active workflow, or moving redundant copies to a dated quarantine. Weak rules include keeping the newest modification date without knowing why it changed or keeping the shortest filename simply because it looks cleaner.
What a matching hash does not prove
- It does not prove that either path is safe to delete.
- It does not compare filesystem permissions, cloud version history, tags, or external database references.
- It does not detect visually similar but byte-different media.
- It does not establish who owns the file or whether retention rules require multiple copies.
The tool reports potential duplicate bytes by counting all but one file in each confirmed group. That figure is an upper bound for review, not a promised storage saving.