The duplicate finder is great when you don’t know what you’re looking for. It scans a folder and automatically groups everything similar. But what if you already know exactly which file you want copies of?
That’s where Reverse Image Search comes in. Instead of grouping everything, you upload one reference file first. Sakarto processes it immediately, then scans your chosen folder and returns only the files that look like that specific reference. The reference is pinned at the top with a protected badge—it can never be accidentally moved or deleted.
With the BlockHash algorithm, it finds copies of your reference even when they’re noisy, heavily compressed, or re-encoded multiple times. BlockHash averages brightness over blocks of pixels instead of reading individual pixels, making it dramatically more tolerant of JPEG compression artifacts, sensor noise, and encoding degradation.
What makes BlockHash reverse search different from aHash?
Both algorithms produce a binary hash and compare using Hamming distance. But they encode brightness in fundamentally different ways:
| aHash | BlockHash | |
|---|---|---|
| Input size | 16×16 pixels (256 total) | 64×64 canvas → 16×16 blocks (256 blocks) |
| Processing | Each pixel compared to overall mean | Each block averaged, then block averages compared to median |
| Sensitivity | Sensitive to individual pixel changes | Noise and compression artifacts are averaged away |
| Speed | Fastest | Very Fast (slightly slower than aHash) |
| Best for | Clean images, exact copies, speed priority | Noisy, compressed, or re-encoded images |
The key insight: When JPEG compression degrades an image, it introduces small errors in individual pixels. But when you average brightness over a 16×16 block—256 pixels—those small errors mostly cancel out. The block average barely changes even when the quality setting drops from 90% to 70%. aHash, which reads individual pixels, sees those errors as real differences and produces a different hash. BlockHash ignores them.
How reverse search works
The standard Find Duplicate Images & Videos workflow scans a folder and compares every file against every other file. That’s O(n²) complexity—fine for a few hundred images, but it gets slower as the folder grows.
Reverse Search does something much smarter. It fingerprints your reference once, then compares each folder file only against that reference. That’s O(n) complexity—linear scaling. A folder of 10,000 images takes roughly the same time per file as a folder of 100. The scan speed depends only on the number of files, not how many of them are similar to each other.
This makes reverse search the faster choice for large folders where you already know what you’re looking for.
The reference protection system
The reference file is treated differently from every other file in the scan. When you upload it, Sakarto immediately:
- Computes its fingerprint using BlockHash
- Shows a thumbnail preview so you can confirm the right file was loaded
- Pins it at the top of the results as soon as scanning starts
- Displays a blue REFERENCE badge on the card
- Prevents it from being moved or deleted—Move and Delete buttons are disabled on the reference card
This last point is critical. If you’re using reverse search to find copies of a file you want to keep, you don’t want to accidentally delete the original. The reference protection system makes that impossible.
How the BlockHash algorithm works
BlockHash follows a straightforward pipeline. Here’s exactly what happens when you run a reverse search:
Step 1: Process the reference file immediately
When you upload your reference file, Sakarto processes it right away—before you even select the folder to search. The image is drawn onto a canvas, divided into 16×16 equal blocks, and the average brightness of each block is computed. The reference card appears immediately with a blue REFERENCE badge, confirming that your file is loaded and ready.
Step 2: Divide each folder file into blocks
For each image in the scanned folder, Sakarto draws it onto a canvas and divides it into 16 equal blocks (a 4×4 grid). In Fast Mode, JPEG files use their embedded EXIF thumbnail instead of the full image, making scans 5–10× faster. Since BlockHash averages brightness over blocks anyway, the tiny thumbnail quality difference rarely affects the result.
Step 3: Average brightness per block
For each block, every pixel is converted to grayscale using the standard luminance formula. The average grayscale value across all pixels in that block is computed. This single number represents the overall brightness of that region. JPEG compression adds small errors to individual pixels, but by averaging 16 or more pixels together, those errors cancel out.
Step 4: Threshold to binary hash
The average brightness of each block is compared to the overall median of all block averages. Blocks brighter than the median become 1; darker become 0. The result is a 256-bit binary hash—one bit per block.
Step 5: Compare against the reference using Hamming distance
To compare a folder file against your reference, Sakarto XORs their 256-bit hashes bit by bit. The number of positions where the bits differ is the Hamming distance. An aspect-ratio pre-check first discards pairs where proportions differ by more than 10%. If the Hamming distance is at or below the threshold, the file is added to the results.
Step 6: Reference pinned first, matches rendered live
The reference card always appears at position 0 with a blue REFERENCE badge. Each matching file is rendered as a card immediately when found—you see results appear live without waiting for the full scan.
What BlockHash reverse search finds well
| Type of copy | How well it works | Why |
|---|---|---|
| Exact copies of your reference | ✅ Excellent | The hash will be identical. |
| Reference saved at different resolutions | ✅ Excellent | Block-level averaging removes resolution differences. |
| Heavily compressed JPEGs at low quality | ✅ Excellent | Block averaging absorbs compression artifacts that would change individual pixels. |
| Re-exported copies in different formats (JPEG → PNG → WebP) | ✅ Excellent | Format conversions change pixels, but block averages remain stable. |
| Scanned photos with sensor noise or print grain | ✅ Excellent | Random noise cancels out when averaged over a block. |
| Re-encoded files with visible compression artifacts | ✅ Excellent | Exactly what BlockHash was designed for. |
| Screenshots of the reference image | ✅ Very Good | Screenshots add slight colour shifts but block averages are preserved. |
| Videos sharing key visual scenes with the reference | ✅ Good | Video frames are averaged. |
| Heavily cropped versions (over 30% removed) | ⚠️ May miss | Removing a large portion changes the block grid significantly. |
| Rotated or mirrored versions | ❌ Won’t find | Block positions change entirely. Use ORB for rotated copies. |
| Images with dramatic colour filters or brightness edits | ⚠️ May miss | Large brightness changes affect block averages. Try dHash or Color Signature. |
| Fine details that differ only within blocks | ⚠️ May miss | BlockHash is coarse by design—it won’t catch pixel-level differences within blocks. |
| Images that share block structure by coincidence | ⚠️ May over-match | BlockHash is a coarse descriptor—use Compare to verify borderline matches. |
Understanding the Hamming threshold slider
The threshold slider determines how strictly a folder file must match your reference to be considered a copy. Lower values = stricter matching.
| Threshold range | What it does | When to use |
|---|---|---|
| 0–5 (Very strict) | Only near-identical hashes match. False positives are very rare. | Finding exact copies and very close re-exports of your reference. |
| 6–15 (Balanced) | Catches resized, re-compressed, and reformatted copies. | Default and recommended. BlockHash at 10–15 often catches everything aHash catches at 15–20. |
| 16–25 (Loose) | Includes more approximate brightness matches. More false positives. | If you’re missing copies that are heavily cropped or significantly different in quality. |
| 30+ (Very loose) | Groups images with broadly similar block brightness distributions. | Only use for exploration. Expect many false positives—always preview before acting. |
Tip: Because BlockHash is a coarse descriptor by design, it often catches everything useful at lower thresholds than you might need with aHash. Start at 8–10 and only raise if you’re missing known copies.
How to use BlockHash reverse search: step by step
Step 1: Select your reference file
Click Choose Reference File in the left panel. Select any image or video from your computer. A preview appears immediately so you can confirm you picked the right file. Sakarto processes the reference file right away—computing its hash before you even select the folder. This means the search starts instantly once you pick a folder.
Tip: The reference file does not need to be inside the folder you’re about to scan. It can be from anywhere on your computer.
Step 2: Select the folder to search
Once a reference file is loaded, the Choose Folder to Search button becomes active. Click it to open a native folder picker (Chrome/Edge). Or drag and drop a folder onto the page. The folder count shows how many files were found. The Start Search button activates once both the reference file and a folder are selected.
Tip: Enable Fast Mode in the toolbar if you’re scanning many JPEG files—it reads embedded thumbnails and is 5–10× faster than loading full images.
Step 3: Start the search
Click 🔍 Start Search. The reference file card appears immediately at the top of the results with a blue REFERENCE badge. A progress bar shows how many files have been scanned. You can switch browser tabs during the search—image processing runs in a background Web Worker and continues uninterrupted. Video processing pauses when the tab is hidden and resumes when you return.
Step 4: Adjust the threshold if needed
Use the Similarity Threshold slider to tune matching sensitivity. Releasing the slider triggers an instant re-search using already-computed hashes—no re-scan needed. If expected copies are missing, raise the threshold. If too many unrelated files appear, lower it.
Step 5: Review matches as they appear
Every time a matching file is found, it appears as a new card next to the reference. The header count updates live. Once the scan finishes, a final summary shows the total number of similar files found.
- Click a card to select it (blue border)
- Ctrl+Click (Cmd+Click on Mac) to add to the compare list (purple border)
- Click the 🔍 icon on hover to preview full size with metadata
- Right‑click any card for the context menu (the reference card has Move/Delete grayed out)
- Click & drag on empty space to box‑select multiple result cards
Step 6: Compare reference vs. match side‑by‑side
Ctrl+Click the reference card and one or more match cards, then click ⚖️ Compare in the toolbar. A modal opens showing all selected files side‑by‑side with their dimensions, file size, path, and a similarity percentage. For 3+ files, a full pairwise similarity matrix is shown. Similarity percentages above 80% are shown in green, 50–80% in amber, and below 50% in red—giving you a quick visual indicator of how close each match is to your reference.
Step 7: Act on matches—Move, Delete, or Copy
Select the files you want to act on (not the reference—it’s protected) and use the toolbar. With Queue Mode on (recommended), files are staged first:
- 📋 Copy — copy filename(s) to clipboard
- 📂 Move — stage matches for move to a named folder
- 🗑️ Delete — stage matches for permanent deletion
- ⚖️ Compare — view selected files side‑by‑side
Warning: Deletions are permanent. The File System Access API bypasses the recycle bin. Always use Queue Mode to review before executing. The reference file cannot be deleted or moved.
Step 8: Queue Mode—review before you commit
When Queue Mode is enabled (the default), clicking Move or Delete stages files rather than acting immediately. Switch to the Move Queue or Delete Queue tab in the sidebar to review what’s staged, remove individual files, then execute when ready.
Reverse Search vs. Find Duplicates: which to use?
| Reverse Search | Find Duplicates | |
|---|---|---|
| What it does | Finds copies of one specific reference file | Groups all similar files in a folder |
| Complexity | O(n) — each file compared against reference | O(n²) — all files compared against each other |
| Speed | Faster for large folders | Slower for large folders |
| Reference protection | Yes — reference pinned and cannot be deleted | No — all files are treated equally |
| Best for | You know exactly which file you’re looking for | You want to see every duplicate group in a folder |
| When to use | ”I need to find every copy of this specific photo" | "I need to clean up my entire photo library” |
Recommendation: Use both. Run Find Duplicates to see the big picture. Then use Reverse Search for specific important files to clean up their copies without risking the originals.
When to use BlockHash vs. the other 6 algorithms for reverse search
Sakarto gives you seven visual algorithms for a reason—each one handles a different type of duplication problem. Here’s when to pick BlockHash over the others:
Color Signature — colour accuracy
Color Signature is the only algorithm that compares actual colour.
Use BlockHash instead: Your reference’s copies are noisy or heavily compressed. BlockHash’s block averaging makes it more tolerant of the degradation that would break Color Signature’s colour comparisons.
aHash (Average Hash) — speed above all else
aHash is the fastest algorithm—it reads individual pixels and compares them to the overall mean. It’s less tolerant of compression artifacts than BlockHash.
Use BlockHash instead: Your reference’s copies show visible JPEG compression artifacts, blockiness, or noise that would cause aHash to produce different hashes for copies that look identical to the human eye.
dHash (Difference Hash) — brightness and exposure-adjusted copies
dHash compares the direction of brightness change between adjacent pixels, making it robust to exposure shifts.
Use BlockHash instead: You’re dealing with compression artifacts and noise rather than exposure adjustments. dHash is more sensitive to pixel-level changes than BlockHash.
pHash (Perceptual Hash) — format conversions and watermarks
pHash uses the Discrete Cosine Transform to extract low‑frequency structural data. It’s more discriminating than BlockHash but also slower.
Use BlockHash instead: You need speed for a large folder and your reference’s copies are visibly noisy or heavily compressed. BlockHash is faster than pHash and more tolerant of degradation.
wHash (Wavelet Hash) — speed and quality balance
wHash uses the Haar Wavelet Transform—similar quality to pHash at lower CPU cost.
Use BlockHash instead: You need the noise tolerance of block averaging. wHash is still sensitive to the pixel-level changes that BlockHash ignores.
ORB (Feature Matching) — rotation, cropping, and perspective
ORB is the only algorithm that handles rotation, cropping, and perspective warping.
Use BlockHash instead: Your reference’s copies are not rotated or heavily cropped. BlockHash is 100× faster than ORB for this use case.
BlockHash — noise-tolerant specialist
BlockHash is the algorithm for noisy, heavily compressed, or re-encoded copies of your reference. Use it when aHash misses copies due to compression artifacts.
Use BlockHash when: Your reference’s copies have been heavily re-compressed, saved at low quality, scanned with visible grain, or re-encoded multiple times. BlockHash finds copies that aHash misses.
Algorithm quick reference for reverse search
| Algorithm | Best for | Colour‑aware? | Handles rotation? | Handles cropping? | Noise‑tolerant? | Speed |
|---|---|---|---|---|---|---|
| Color Signature | Same colour palette, social media re‑uploads | ✅ Yes | ❌ No | ❌ No | ⚠️ Moderate | Fast |
| aHash | Large folders, speed priority | ❌ No | ❌ No | ❌ No | ⚠️ Low | Fastest |
| BlockHash | Heavily compressed, noisy images | ❌ No | ❌ No | ❌ No | ✅ High | Very Fast |
| dHash | Brightness/exposure‑adjusted copies | ❌ No | ❌ No | ❌ No | ⚠️ Moderate | Very Fast |
| pHash | Format conversions, watermarks, precision | ❌ No | ❌ No | ❌ No | ⚠️ Moderate | Fast |
| wHash | Speed + quality balance | ❌ No | ❌ No | ❌ No | ⚠️ Moderate | Fast |
| ORB | Rotated, cropped, perspective‑warped | ❌ No | ✅ Yes | ✅ Yes | ✅ High | Slower |
Privacy: your files never leave your device
Like every Sakarto tool, the reverse image search runs entirely in your browser:
- Zero network activity after page load. Open DevTools → Network tab and verify: no outbound requests during any search, compare, or file operation. Your reference file and folder contents are never transmitted anywhere.
- No accounts, no cookies, no analytics. The only localStorage data is your OS detection and checkbox preferences. No file names, paths, or scan results are ever saved.
- Folder access is scoped and session‑only. Permission is granted only for the specific folder you select, lasts only while the tab is open, and is revocable at any time from browser site settings.
- Purely static—no backend. Sakarto is HTML, CSS, and JavaScript. There is no server, no database, and no API receiving any data from you.
Frequently asked questions (BlockHash reverse search specific)
“How is BlockHash reverse search different from aHash reverse search?”
Both compare a folder file’s hash against the reference using Hamming distance, but they build the hash differently. aHash shrinks to 16×16 individual pixels and compares each to the overall mean—it reads individual pixel values, which are sensitive to compression noise. BlockHash divides the image into 16 equal blocks and computes the average brightness of each block before comparing to the median. By averaging over a 16×16 area instead of a single pixel, compression artifacts, scan noise, and encoding differences largely cancel out and disappear from the hash. BlockHash is the better choice when your reference’s copies are heavily re‑compressed JPEG versions, scanned at different DPIs, or saved through different encoders. The trade‑off: it’s a coarser descriptor and produces more false positives at loose thresholds than aHash.
”Does my reference file need to be inside the folder I’m scanning?”
No—select it from anywhere on your computer. If it also exists inside the scanned folder, Sakarto detects and skips it automatically (matched by filename, file size, and last‑modified timestamp). The reference card is always pinned at position 0 and is never treated as a scan result, even if an identical file is found in the folder.
”I know a copy of my reference exists in the folder but it isn’t appearing. What should I try?”
First, raise the threshold slider toward 15–20. Second, check aspect ratios—pairs differing by more than 10% are excluded by the pre‑check before hashing runs. Third, consider whether the copy has been rotated or heavily cropped—BlockHash, like all grid‑based hashes, cannot match geometrically transformed copies. Switch to ORB Reverse Image Search for rotation and perspective‑distorted copies. Fourth, if the copy is a very different resolution (e.g. a tiny social media thumbnail vs a full‑resolution original), the aspect ratio may have changed slightly—check both the pre‑check threshold and the similarity threshold.
”I’m seeing too many unrelated images as matches. How do I reduce false positives?”
BlockHash is intentionally coarse—it sacrifices precision for noise tolerance. At thresholds above 10, images that merely share a similar broad brightness layout (mostly bright top, dark bottom, etc.) can match your reference even if they look nothing like it. Lower the threshold to 4–7 first. If false positives persist at strict thresholds, switch to a more discriminating algorithm: pHash (frequency‑domain encoding) or Color Signature (also compares colour) will produce far fewer false positives for the same threshold range.
”When is BlockHash the best choice for a reference search?”
BlockHash is specifically useful when your reference’s copies have been degraded in a way that affects individual pixels more than overall block structure—primarily heavy JPEG re‑compression (quality 20–40), re‑scanning on different hardware, screenshots taken at different quality settings, or copies downloaded from platforms that aggressively recompress images. In all these cases, individual pixel values change noticeably due to encoding noise, but the block‑average brightness across the 16 regions stays very stable. BlockHash will find copies that aHash misses purely because of compression artifacts.
”How do I decide which file to keep when I find a match?”
Ctrl+Click the reference and a match card, then click Compare. The modal shows both files side by side with dimensions, file size, format, and a similarity percentage. Generally: keep the larger file size (more bytes = less compression = better quality). If one is lossless and the other compressed, keep the lossless version. Check dimensions too—a 4K original is worth keeping over a 1080p re‑export even if the file sizes are similar.
”Can I recover files after deleting them?”
No. Sakarto’s remove() call via the File System Access API permanently deletes files without going through the OS Recycle Bin or Trash. The reference file is fully protected and cannot be deleted regardless. For matched files, use Queue Mode: stage them, preview each one, and only execute when certain. Using Move to a “Sakarto‑Duplicates” subfolder first is a safer alternative to deleting outright.
”Does this work on Firefox or Safari?”
Reference processing, folder scanning, result display, and the Compare modal all work in Firefox and Safari. Move and Delete require the File System Access API (Chrome 86+ and Edge 86+ only). In other browsers, complete the search, review results, and use Download List to export a report for manual file management.
Final thoughts
BlockHash reverse search is the tool you reach for when your reference’s copies are noisy, heavily compressed, or degraded. It’s the most noise-tolerant algorithm in Sakarto’s reverse search toolkit, finding copies that aHash misses purely because of compression artifacts.
It’s particularly effective for:
- Heavily compressed JPEG collections. Images saved multiple times at low quality settings.
- Scanned photos and documents. Flatbed scanner output with sensor noise and grain.
- Social media downloads. Platforms like Instagram, Facebook, and X apply aggressive re‑compression that degrades images significantly.
- Noisy reference files. When your reference itself is noisy or compressed, BlockHash handles it better than pixel‑precise algorithms.
Where BlockHash falls short—rotated, colour‑graded, or heavily cropped copies—other Sakarto algorithms fill the gap. Use ORB for rotated or cropped copies, pHash for precision, or Color Signature for colour‑aware matching.
But for noisy, messy, and heavily compressed image libraries, BlockHash is the algorithm that finds the copies the others miss.
Ready to find every copy of your reference image or video in noisy collections?
- Open BlockHash Reverse Search — free, browser‑based, no install
- Try Find Duplicates with BlockHash — auto‑group all similar files without a reference
- Explore All 7 Reverse Image & Video Algorithms — compare with Color Signature, aHash, dHash, pHash, wHash, and ORB