Compare two folders

Folder comparison answers a different question from file comparison: not "what changed in this file" but "which files changed at all". It is the tool you want when checking a deployment against a build output, verifying a backup, auditing what an installer touched, or working out why two supposedly identical environments behave differently.

This runs entirely in your browser. The folders are read from your disk through the File System Access API after you explicitly grant permission, contents are hashed locally in background threads, and nothing is transmitted anywhere. That makes it usable on a machine where uploading the directory to a website would be unacceptable or forbidden.

How files are matched and compared

The comparison is staged the way desktop tools stage it, because reading a file through the browser's file system API is roughly a hundred times slower than a native filesystem call. Skipping unnecessary reads is the entire performance story.

• Different sizes settle the question immediately — the files cannot be identical, and neither is read.
• Same size is inconclusive, so both files are hashed and the digests compared. With content comparison switched off, the timestamp decides instead, subject to the tolerance you set.
• Orphans — files present on only one side — are hashed and matched against each other when rename detection is on, so a moved file is reported as a rename rather than as a deletion plus an addition.

Hashing uses xxHash64 running as WebAssembly across a pool of workers sized to your CPU. That is a non-cryptographic hash, chosen because this is an identity check rather than a security boundary, and it runs roughly an order of magnitude faster than SHA-256. Files are streamed in four-megabyte chunks and never buffered whole, which matters because the browser's built-in crypto.subtle.digest has no incremental interface and simply cannot hash a file larger than available memory.

Timestamp tolerance, and why it exists

Filesystems disagree about time. FAT32 stores modification times with two-second precision, so a file copied from NTFS to a USB stick can appear to have changed when nothing did. Archive extraction, cloud sync clients and build tools all rewrite timestamps freely. The default two-second tolerance absorbs the most common of these artefacts; raise it to 3600 if you are comparing across a timezone boundary that has been applied inconsistently.

This only matters when content comparison is switched off. With hashing enabled, timestamps are ignored entirely for files of matching size, which is the more trustworthy answer.

What this cannot do, honestly

A browser tab is not a desktop application, and several of Beyond Compare's capabilities are not merely unimplemented here but genuinely impossible:

• No sync or mirror. Browsers cannot set a file's modification time. A mirror operation would therefore stamp every copied file with the current time, and the next comparison would report the entire tree as newer on one side. Shipping that would be worse than not shipping it, so this tool is deliberately read-only and never writes to your disk.
• No file metadata beyond name, size and timestamp. POSIX permissions, owner and group, Windows attributes, symlinks and inode identity are all unavailable through the web platform.
• No remote sources. FTP, SFTP, WebDAV and S3 need raw sockets or a relay server. A relay would mean your files travelling through somebody else's infrastructure, which defeats the entire point of this tool.
• No git integration. A web page cannot be invoked asgit difftool and return a blocking exit code.

What it does cover is the part people actually use most: scan two trees, filter the noise, find the files that differ, and look at one of them closely.

Practical limits

Up to about five thousand files per side feels instant. Between five and fifty thousand it takes a few seconds, mostly spent hashing. Beyond that, keep the ignore list aggressive — excluding node_modules, .git and build output typically removes ninety per cent of the entries in a project directory and costs you nothing, which is why those are ignored by default. The results table renders the first five thousand matching rows and tells you when it has truncated.