Read Frog: an open source browser extension for immersive translation and language learning

What Read Frog solves, and who it is actually for

Read Frog is a browser extension for language learners. Its stated goal in the README is to make everyday web reading into a language learning exercise, with the project describing itself as "an open-source AI-powered language learning extension for browsers" that supports immersive translation, article analysis and multiple AI models. That framing matters, because it puts the extension in a different category from a general page translator. The intended user is someone reading a foreign-language article and wanting the original text to stay visible while a translation sits beside it.

The feature list backs that up. The README names bilingual or translation-only modes, selection translation, context-aware translation, subtitle translation, text-to-speech and batch requests. Those are reading and study features, not publishing features. If your actual problem is shipping a localised product page, this is the wrong shape of tool.

The second constraint is that Read Frog does not appear to ship its own translation model. The package manifest pulls in a long list of provider SDKs, including @ai-sdk/openai, @ai-sdk/anthropic, @ai-sdk/deepseek, @ai-sdk/google, @ai-sdk/mistral and @ai-sdk/amazon-bedrock, among others. The README advertises "20+ AI Providers". The practical reading is that you bring a key for a provider you already use, and the extension routes requests there. That is a real cost and a real dependency, and it is the first thing to settle before installing anything.

How the extension is put together: WXT, React and provider SDKs

The repository is a TypeScript project built with WXT, a browser extension framework. The wxt.config.ts file at the repository root is the build entry point, and the package scripts show the shape of the toolchain: wxt for development, wxt build for production, with separate targets for Edge and Firefox. The Firefox build is explicitly MV3, which is worth noting because it tells you the maintainers are targeting the newer manifest format on that browser rather than the legacy one.

The workspace is a pnpm monorepo, with pnpm-workspace.yaml and nx.json present. Source lives under src/, the extension assets under public/ and assets/, and the user-facing documentation under readmes/ in nine languages. Tests run through vitest, with vitest.config.ts and vitest.setup.ts at the root, and linting and formatting are handled by oxlint and oxfmt rather than the more common ESLint and Prettier combination.

The data flow is the part that matters for anyone evaluating privacy. A page is read in the browser, the text to be translated is sent to whichever AI provider you configured, and the returned text is rendered back into the page. The provider SDKs in package.json are the evidence for that routing. The .env.example file is about the extension's own runtime URLs rather than model endpoints: it lists optional overrides such as WXT_API_URL, WXT_WEBSITE_URL and WXT_OFFICIAL_SITE_ORIGINS, and notes that production values are used by default. It also lists WXT_POSTHOG_HOST and WXT_POSTHOG_API_KEY as required in production, which means the published build includes PostHog analytics. That is a detail worth knowing before you install, and the README does not discuss it.

Installing Read Frog and running a first translation

There is no self-hosted server to stand up. The README's download table points at three store listings: the Chrome Web Store, Microsoft Edge Addons and Firefox Add-ons, with a China mirror link for Chrome. The same table is the canonical answer to "Read frog chrome extension" questions, so start there rather than from a source build.

If you want to build from source instead, the repository is a pnpm workspace and the scripts are defined in package.json. The postinstall hook runs wxt prepare, so dependencies and the WXT environment are set up in one step.

Where Read Frog falls short

The README is candid about one thing: it states that Read Frog "is currently under active development" and invites feedback on issues. The last push to the repository was on 2026-09-09, and releases v1.46.9, v1.46.8 and v1.46.7 landed on 2026-09-09, 2026-09-05 and 2026-09-02 respectively. The release cadence is fast, which cuts both ways: fixes arrive quickly, and so do behaviour changes.

The larger limitation is architectural. Because translation is delegated to a third-party model provider, output quality is not something the project controls. Two users on different providers will get different translations of the same page, and a provider outage or a rate limit becomes your outage. The README does not document rollback behaviour or offline fallback, so plan for the extension to be unavailable when your provider is.

Cost is the second constraint. Nothing in the repository suggests Read Frog bundles model credits, so every translated page is billed by your provider. On a long article with batch requests enabled, that adds up in a way a flat-rate translation subscription does not. The README also does not describe how much text is sent per request, which makes it hard to estimate spend in advance.

Finally, the licence. The project is GPL-3.0 and the README carries a separate section headed "Commercial License Grant". If you intend to embed this in a product, read both before you build on it.

Read Frog compared with Immersive Translate and KISS Translator

The obvious comparison is Immersive Translate, which appears in the same search space and solves the same core problem: bilingual page rendering in the browser. The difference in approach is where the intelligence lives. Immersive Translate is a commercial product with its own translation backend and subscription, so the user does not supply a provider key. Read Frog inverts that: the extension is open source under GPL-3.0, and you supply the model access. You get control over which model handles your text and you avoid a per-seat subscription, but you take on key management, provider billing and the variability of model output.

KISS Translator is the closer match philosophically, since it is also an open source browser translation extension rather than a hosted service. The distinction Read Frog draws is in scope: its feature set is oriented around study, with text-to-speech, subtitle translation and custom AI actions named in the README, rather than translation alone. If you only want pages translated and nothing else, the extra surface area is overhead you will not use.

The honest summary is that all three do bilingual reading. Pick Read Frog if you want the model choice and the study features and are willing to run your own key. Pick a hosted product if you would rather not think about providers at all.

Licence, maintenance and what an upgrade costs you

Read Frog is licensed under GPL-3.0. For an individual installing the extension from a browser store, that is unremarkable. For anyone modifying the source and distributing the result, GPL-3.0 carries obligations, and the README's separate "Commercial License Grant" section exists precisely because those obligations do not suit every commercial use. This is not legal advice; if your use is commercial, take the licence text and that section to someone qualified.

Upgrade cost is low in the ordinary case. Store installs update themselves, and the project ships often: three releases in the eight days before 2026-09-09. The changeset tooling in the repository (.changeset/ and a release script running changeset git-tag) shows the maintainers run a structured release process rather than tagging ad hoc.

The cost that is not low is the source-build path. Building locally means tracking a pnpm workspace with Nx, WXT, oxlint and oxfmt, and rebuilding for each browser target you support. The .env.example file also implies that a production build needs values for WXT_GOOGLE_CLIENT_ID, WXT_POSTHOG_HOST and WXT_POSTHOG_API_KEY, so a self-built copy is not simply a compile of the published extension.

What to check before you commit to Read Frog

Three things are worth verifying against the current documentation rather than this article. First, whether your preferred provider is among the 20+ the README claims and whether your existing key works with it, since the provider list is the whole basis of the extension's output. Second, what the published build sends where: the .env.example file lists PostHog as required in production, and the README does not describe what is collected.

Third, the target sites. Context-aware translation and subtitle translation are named features, but the README does not enumerate which video platforms or page types are supported. Test on the sites you actually read before deciding, because a translation extension that fails on your main reading source is worth nothing regardless of its feature list.

The tutorial at readfrog.app/docs is the place to start for configuration walkthroughs, and the Discord listed in the README is where the maintainers take questions.

Editorial conclusion

Read Frog suits individual language learners who already hold an API key with a provider such as OpenAI, DeepSeek or Anthropic, and who want bilingual pages rather than a finished translation. It is the wrong tool if you need a managed service with a support contract, or if you cannot run or pay for model calls. Before adopting it, check the licence terms for your use case, confirm which providers your key covers, and read the tutorial at readfrog.app/docs to see whether your target sites are handled.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. mengxi-ream/read-frog on GitHub
3. Project website
4. README
5. Releases