Search by Image: a reverse image search extension for Chrome, Edge and Safari
Browser extension for reverse image search, available for Chrome, Edge and Safari
At a glance
- What is it?
- Search by Image is a GPL-3.0 browser extension that routes an image from any page, your clipboard or a captured screen area into more than 30 reverse image search engines. It is maintained by one author, and its value depends on how much you trust the engines it hands your images to.
- Who is it for?
- Search by Image suits journalists, researchers, photographers and shoppers who already know which engines they trust and want one context menu instead of five tabs. It is the wrong tool if you need server-side, automated or headless matching, because every search runs through a third-party engine in your browser.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 96 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What Search by Image does that a Google Images tab does not
The problem is not that reverse image search is hard. It is that a single image often needs several engines to produce a useful answer, and each engine has its own upload flow. Search by Image collapses that into one action: right-click or click the toolbar button, pick an image, and the extension forwards it to whichever engines you have enabled. The README lists the intended audiences directly: journalists and researchers checking whether an image is authentic or recycled, photographers tracking where their work appears, and shoppers hunting for a product at a lower price. Those are three different jobs that happen to share the same mechanical step.
The engine list is the real feature. The README says the extension supports more than 30 engines and points to a wiki page for the full list, and engines can be toggled and reordered from the options page. That ordering matters more than it sounds: a photographer chasing reposts and a researcher checking a conflict photo want different first results, and the extension lets each of them set that once instead of every time. The README also mentions Yandex and Google in the repository topics, so those two are part of the supported set, but the authoritative list lives in the wiki rather than in the README itself.
Search modes: URL, image file, capture, browse and clipboard
The mechanism is deliberately shallow. The extension does not index anything and does not run a model locally. It detects the image under the area you select, then constructs a request to the chosen search engine using either the image URL or the image bytes. The README states that images at the selected area are detected regardless of how they were embedded in the page, which covers CSS backgrounds, lazy-loaded elements and images inside shadow DOM, the cases where a naive right-click fails.
The five modes exist because that URL-versus-bytes distinction has consequences. Select URL is the default and is the cheapest path: the engine fetches the image from its original host. Select image sends the file instead, and the README recommends it for sites that block direct linking, such as private or authenticated pages. Capture searches with a region of the page you draw yourself, which is the only mode that works when the thing you want to search is not an image element at all, for example a canvas or a video frame. Browse takes an image from your device and also accepts clipboard pastes. URL lets you type or paste an address directly.
The README notes that the search mode can be set independently for the context menu and the toolbar button. That is a smaller detail than it looks. It means you can keep the context menu on the fast URL mode and put the slower file-upload mode behind the toolbar button for the private-site cases, without switching settings each time.
Installing Search by Image and running a first search
For normal use you do not build anything. The README links store listings for Chrome, Firefox, Edge, Opera, Samsung Galaxy and Safari, with separate App Store links for iPhone and Mac. Install from the listing that matches your browser and the extension appears in the toolbar.
If you want to run the code from source, the repository is a Node project built with gulp and webpack. The package.json exposes one build script per browser target, and a production variant that also produces a zip. The Chrome production build is:
npm install
npm run build:prod:chromeThe scripts set TARGET_ENV to the browser name and NODE_ENV to production, then run gulp build. The output is a directory you load as an unpacked extension from your browser's extension page. There is no documented dev server; this is a static bundle, not an application with a backend.
Once installed, the first real use is a context-menu search. Open a page with an image, right-click the image, and the extension offers a submenu of the engines you enabled. Choosing one opens a new tab on that engine's results page. If the image sits on a site that blocks hotlinking, switch the context menu mode to Select image in the options so the extension uploads the file instead of passing the URL. To search something that is not an image element, use Capture and drag over the region you want.
The honest limits: one maintainer, third-party engines, and no automation
The extension is not archived and its last push was on 2026-06-27, with v8.5.4 released on 2026-06-16. That is a maintained project by the only measure available here, but the repository is a single-author effort (Armin Sebastian, per the licence header and package.json author field) and the release cadence shows small version bumps rather than large ones. If your workflow depends on a specific engine, you are depending on a chain: the extension, the engine, and the engine's willingness to accept uploads from a browser extension.
That chain is the main failure mode. Search by Image does not perform any matching itself. If an engine changes its upload endpoint, rate-limits automated submissions, or drops reverse image search, the extension cannot compensate; the affected engine simply stops returning useful results until the project ships an update. The README does not document any fallback, retry behaviour or per-engine status reporting, so a broken engine looks the same as a bad match.
It is also the wrong tool for anything programmatic. There is no documented CLI, no API and no headless mode. If you need to check thousands of images on a schedule, or match a hash against a database you control, this extension is a manual browser tool and you should be looking at an image-matching library or a hosted vision API instead. And because it sends either the image URL or the image file to a third party, it is unsuitable for confidential material regardless of which mode you pick.
How it compares with TinEye and with Google's own upload page
The closest single-purpose alternative is TinEye, which is also a reverse image search engine rather than an extension. The difference in approach is architectural. TinEye runs its own index and its own matching, so it can tell you where else an image appears and when it was first found, but it only answers with TinEye's index. Search by Image is a router: it holds no index and owns no matching, and its value is the number of engines it can reach from one menu. If you need one engine's specific index, go to that engine. If you need to compare what several engines say about the same image, the router wins.
Google's own image upload page is the other comparison, and it is the one most people already use. It accepts a file or a URL and returns Google's results. Search by Image does the same thing but adds the engines Google does not cover, keeps your engine selection between sessions, and works from the page you are already on rather than a separate tab. The trade-off is transparency: with Google's page you know exactly where the image went. With the extension you are trusting a list of engines, some of which you may not have chosen deliberately. That is worth checking in the options page before you use it on anything sensitive.
Licence and upgrade cost for anyone forking it
The package.json declares GPL-3.0-only and the README states the software is released under the GNU General Public License v3.0, with copyright held by Armin Sebastian from 2017 to 2026. For an end user installing from a store, the licence is mostly invisible. For anyone modifying and redistributing it, the copyleft terms apply to the derivative work, and the source must be made available under the same licence. This is a summary of what the repository states, not legal advice; read the LICENSE file before you ship a fork.
Upgrade cost is low by design. The extension has no server component and no database, so updating means installing a new build or pulling the latest source and rebuilding. The repository keeps a CHANGELOG.md at the top level, and the release tags (v8.5.2, v8.5.3, v8.5.4) are patch-level, which suggests the maintainer is fixing engines and small behaviours rather than changing the architecture. The practical cost of staying current is the rebuild, not a migration.
Editorial conclusion
Search by Image suits journalists, researchers, photographers and shoppers who already know which engines they trust and want one context menu instead of five tabs. It is the wrong tool if you need server-side, automated or headless matching, because every search runs through a third-party engine in your browser. Before adopting it, build the extension from the repository with npm run build:prod:chrome and load the unpacked output, then confirm the engines you actually rely on are still listed in the wiki, since the extension only passes your image along and cannot fix an engine that has changed or gone.
Frequently asked questions
What is Search by Image?
It is a browser extension that makes reverse image searches possible from the page you are on, and the README states it comes with support for more than 30 search engines. Images can come from the page, your device, the clipboard, or a captured area.
How do I use the Search by Image extension?
Right-click an image on a page and pick one of the engines you enabled, or use the toolbar button. The README notes the search mode can be set independently for the context menu and the toolbar, and that Select URL is the default mode.
Can I use Search by Image on an iPhone?
Yes. The README links a Safari extension listing on the App Store for iPhone, alongside a separate Mac App Store link and store listings for Chrome, Firefox, Edge, Opera and Samsung Galaxy.
How do I use Search by Image in Firefox?
The README links a Firefox add-on listing on addons.mozilla.org, and the repository also exposes a build:firefox script for building the extension from source. The search modes and the engine selection work the same way across the supported browsers.
Can you search by image without uploading a file?
Yes. The default Select URL mode searches with the image URL, so the engine fetches the image from its original host rather than receiving a file from you. The README recommends the Select image mode only for sites that do not allow direct linking.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/dessant-search-by-image)