Same name, same size and visual similarity are not proof of an exact duplicate
Two files named final.pdf can be different versions, while final-copy.pdf can remain byte-for-byte identical to its source. Filename-only checks therefore create both false positives and missed copies.
A photo can look almost the same after compression, rotation or re-encoding while its bytes have changed. Current FileNest finds exact content copies only; it does not present similar-photo detection as a shipped feature.
- Same name ≠ same content.
- Same size ≠ same content.
- Looks similar ≠ byte-identical.
- Exact duplicate = identical SHA-256 across candidate contents.
Prefilter by byte size before reading candidate contents
Byte-identical files must have the same size, so different sizes can be ruled out first. Unique-size files do not need content reads just to make the scan look exhaustive.
Only same-size candidates continue to SHA-256. The current workspace compares candidate contents locally in the browser rather than uploading working-file contents to FileNest for duplicate detection.
Worked example: three 'final' reports before a project handoff
It is Friday and you are handing a project folder to a teammate. It contains report-final.pdf, report-final-copy.pdf and report-final-approved.pdf. The names suggest copies, but 'approved' might actually contain a later sign-off. Do not choose a file to delete based on its name or thumbnail, especially before keeping a backup.
Keep the originals, then explicitly select the files you want FileNest to inspect. If two reports appear in one exact-duplicate group, their content fingerprints match; a third report outside that group is not automatically the wrong version. Check approval status, paths referenced by the project and the handoff list before the person responsible decides which copies, if any, can be removed. If the scan says partial, stopped or unreadable, resolve the missing coverage before treating an unlisted file as checked.
- Keep a recoverable original; the duplicate finder does not delete your files.
- Matching content fingerprints do not make different filenames, path references or approval purposes interchangeable.
- Check project dependencies before choosing to delete or archive a copy on your own device.
Stopped or unreadable scans must remain visibly partial
If a scan is stopped or a candidate cannot be read, the result must not be presented as complete coverage. Current FileNest preserves partial, stopped and unreadable boundaries, and its CSV report records scan status and candidate coverage.
This prevents 'no more duplicates shown' from being mistaken for 'every candidate was successfully checked'.
Confirm duplicates without automatic deletion
Even byte-identical files can live at paths referenced by projects, scripts or human procedures. Current FileNest reports duplicate groups and evidence but does not automatically delete, move or overwrite files.
After cleanup, use Batch Renamer if the remaining files still need project names, dates, numbering or client-approved targets. Core renaming remains free; recurring regex, CSV mapping or saved templates are the Pro value layer.
Current browser boundary
The current duplicate finder accepts up to 500 explicitly selected files per scan for browser stability. That is not a conversion-credit limit; exact duplicate detection remains free.
A browser can inspect only the files you explicitly select and grant to the page. This is not the same as scanning an entire hard drive.