mouse-dictionary: a dictionary that answers inside a click

One click, one sixtieth of a second

Mouse Dictionary is described simply as a super fast browser dictionary, and the feature list leads with the number that matters for a lookup tool: super quick response time, one sixtieth of a second.

That figure is the design constraint behind the whole project. A dictionary that takes a second is a tool you open in another tab. A dictionary that answers in a frame is a tool you do not think about, and the difference is whether you keep reading or you break your flow to look something up in another window.

The other features are in service of the same goal. There is smart phrase detection, so a lookup can cover a multi-word expression rather than only the word under the pointer. There is automatic word separation, with the example given being camelCase turned into camel case, which is the case that makes a plain single-word lookup useless in technical reading. There is an option to add your own data, so a user can extend the dictionary rather than being stuck with what shipped. And there is a customizable view, so the popup does not fight the page underneath it.

The README is a project page rather than a manual, with screenshots for English to Japanese and Japanese to English, and a short list of features above a demo clip. The community reach is visible in the German section, which points at two community articles about using the extension with a German dictionary rather than shipping one itself.

Where it works, and the Evernote caveat

The list of documents the extension can read over is the most practically useful part of the README, because it defines where the popup appears and where it does not.

HTML is the base case. PDF is supported, and there is a built-in PDF viewer in the project, based on PDF.js, which is how a browser extension gets a text layer to work with inside a PDF. YouTube captions are supported, which is the case that catches a word in a spoken video. Notion is supported. Evernote is supported, with a caveat that points to the separate Mouse Dictionary iframe support extension.

That caveat is worth reading carefully. The iframe support extension exists because Evernote renders its content in a frame, and a browser extension needs an explicit relationship with that frame to inject itself. It is an extra install, and the README is honest that the main extension alone does not cover the Evernote case.

The list ends with an ellipsis, which is the right way to signal that other sites are handled on a case by case basis rather than claiming a coverage that cannot be maintained. For a user this means the extension is a browsing companion that covers most text on the web, not a uniform layer over every application.

The messaging API, and how another extension uses it

Mouse Dictionary supports receiving cross-extension messages, and the README points to the Mouse Dictionary iframe support extension as a worked example of a sender.

The point of the feature is that a lookup is useful even when the word did not come from the mouse. The protocol is small: a message with a type field that must be text, and a text field carrying what you want looked up.

const MD_EXTENSION_ID = "dnclbikcihnpjohihfcmmldgkjnebgnj";

chrome.runtime.sendMessage(MD_EXTENSION_ID, {
  type: "text",
  text: "rained cats and dogs",
});

That is the whole interface, and it is a good design. An extension that already has the text, a reading assistant that has a selected phrase, or an application that wants to show a definition, can hand the string over and let Mouse Dictionary do the part it is good at, without duplicating the dictionary or the popup.

The cost is that the sender needs the extension id, which is why the README spells it out, and the two extensions have to be installed together. For a user who wants to install one thing, that is friction, and for a developer building on top of it, it is a dependency worth having.

The build: one script per browser, Node 26 and Biome

The development section is short and assumes you want to build for a specific browser. The preparation is Node.js 26 or newer and npm install, and then a build and a release command for each target:

npm run build-chrome   # Debug build
npm run release-chrome # Release build

with the same pair for Firefox and for Safari, and the README pointing at package.json for the other commands.

The scripts themselves are more informative than the names suggest. The Chrome build runs a manifest generator for the development environment, then a res step, then the actual build. The res step is node tools/bundle_json.ts followed by node tools/make_dict.ts, with a res-force variant that passes a force flag, and that is where the dictionary data is assembled into the format the extension ships. The release scripts switch the manifest to production and use res-force, so a release build regenerates the data rather than reusing what is in the tree.

There are also variants for Vivaldi, built on the Chrome pipeline with an activate_extension flag, and scripts for linting with biome check, formatting with biome format --write, type checking with tsc for both the project and the tools directory, and the test suite with vitest run, alongside watch and coverage variants. The test configuration has its own vitest.config.ts and vitest.setup.ts, and the repository carries a codecov configuration and a .qlty directory for maintainability analysis.

The project is written in TypeScript with the type module flag set, and the module version is 1.7.3 in package.json, which is slightly ahead of the latest release tag.

Where mouse-dictionary is the wrong choice

The first wrong-tool case is a language the bundled data does not cover. The dictionary data is ejdict-hand, an English to Japanese set, so the English to Japanese and Japanese to English flows are the supported ones, and the German experience in the README is a community article about pairing the extension with a German dictionary rather than something the project ships. The option to add your own data exists, but that is a project for the user.

The second is a user who needs citations, definitions from a scholarly source, or a translation in a context where a compact popup is not enough. This is a lookup aid, and the definition it shows is a dictionary gloss, not a reference work.

The third is a workplace where extensions are not permitted, which is common and which no amount of the extension's own quality changes. A browser-based dictionary that needs an install is simply unavailable in that environment, and the alternative is a system dictionary or a search engine, which is the trade the extension is trying to beat.

There is also the data question for a cautious user. The dictionary content is bundled with the extension, which is good for privacy and for working offline, and it also means the definitions you trust are the ones a particular release shipped. The third-party data section lists the sources and their licences, which is what you would want to check before relying on it for study.

MIT, the bundled data licences, and a project that keeps moving

Mouse Dictionary is published under the MIT licence, and the repository is not archived, with the last push on 2026-10-04 and the default branch on master. The release list shows v1.7.2 from 2026-09-20, v1.7.1 from 2026-01-23 and v1.7.0 from 2025-04-29, so the project ships a few times a year rather than continuously.

The third-party data section is the part to read before shipping it inside anything. The dictionary data comes from ejdict-hand, which is in the public domain. The images come from the WPZOOM Developer Icon Set under CC BY-SA 3.0 and the Heroicons UI icon set under MIT, and the built-in PDF viewer is based on PDF.js under Apache-2.0, from the author's own fork. The JavaScript libraries the project uses are listed in package.json and in a license.html published with the releases.

That inventory is what makes the project usable in a commercial context, because the code licence and the data licences are different questions and both are answered.

The repository layout matches a browser extension project, with src/ for the extension source, data/ for the dictionary content, static/ for the assets, tools/ for the build scripts that package.json calls, a __test__/ directory, and the biome, codecov and vitest configuration at the root. The README also links a Japanese tutorial article, which is a good indication of where the project's users are.

Editorial conclusion

Adopt mouse-dictionary if you read English or Japanese on the web and want definitions without switching to another window, especially if you work with PDFs, YouTube captions or Notion, and if you are a language learner the bilingual lookups are the point. Do not adopt it as a general reference work, since the dictionary data is the ejdict-hand English-Japanese set, and the German experience in the README is a community article rather than a bundled dictionary. Before you install, check which languages the bundled data covers, and if you extend it, remember the project asks contributors to run npm run test and npm run lint before committing.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. wtetsu/mouse-dictionary on GitHub