How I built a Chrome extension that runs Stockfish using WebAssembly (fully local chess analysis)

physical — Fri, 05 Jun 2026 17:37:32 +0000

How I built a Chrome extension that runs Stockfish using WebAssembly

Recently I experimented with running a full chess engine directly inside the browser, without any backend services.

The result is a Chrome extension that runs Stockfish locally using WebAssembly.

This post is a breakdown of how it works, why I built it, and what challenges I ran into.

🚀 Motivation

I wanted to explore a simple question:

How far can we push browser-based computation today?

Specifically:

Can a chess engine run fully in the browser?
How viable is WebAssembly for CPU-heavy workloads?
What limitations does Chrome Extensions (Manifest V3) introduce?

🧠 Architecture overview

The system is built around three main components:

Stockfish compiled to WebAssembly
Chrome Extension (Manifest V3)
Message-based communication between extension contexts

Everything runs locally — there is no backend, no API calls, no server-side logic.

⚙️ How it works

1. WebAssembly Stockfish

The Stockfish engine is compiled into WebAssembly so it can run inside the browser runtime.

This allows near-native performance for heavy computation tasks.

2. Chrome Extension (MV3)

The extension is structured using Manifest V3:

Background service worker
Content scripts
UI popup

One of the main challenges is that service workers are not persistent, which affects how long-running computations must be handled.

3. Communication layer

Because of MV3 constraints, the architecture relies heavily on message passing between:

UI → background
background → engine
engine → UI

Designing this cleanly was more important than raw performance.

⚡ Challenges

1. Extension lifecycle (MV3)

Service workers can be terminated at any time, so you cannot rely on persistent execution.

2. WASM initialization cost

Loading and initializing Stockfish takes noticeable time, so startup optimization matters.

3. Performance vs responsiveness

Running a chess engine can easily block the UI if not handled carefully.

📊 What I learned

WebAssembly is already production-ready for CPU-heavy tasks
Architecture matters more than raw computation speed in browser apps
Chrome Extensions introduce real constraints that affect system design
Most complexity comes from lifecycle + messaging, not the engine itself

📦 Source code

GitHub:
https://github.com/physicalaff/Knight-Chess-Helper

🧩 Conclusion

This was more of an experiment than a product.

It helped me understand how far modern browsers can go when pushed beyond typical web app workloads.

If you’ve worked with WebAssembly or Chrome Extensions, I’d be curious how you handled similar constraints.

Building a High-Performance Local Chess Assistant Extension with WebAssembly Stockfish and Manifest V3

physical — Sat, 23 May 2026 12:21:44 +0000

Hey everyone! 👋

I wanted to share a project I’ve been working on recently: Knight - Chess Helper. It’s an advanced browser extension designed to assist and analyze chess games on Chess.com entirely locally and in real-time.

Building a tool like this within the constraints of modern browser security policies (Manifest V3) was a massive technical challenge, and I’d love to walk you through how I solved it.

👉 Check out the full repository here: https://github.com/physicalaff/Knight-Chess-Helper

🛠️ The Technical Challenge: Bypassing CSP & Sandboxing

Modern platforms like Chess.com use very strict Content Security Policies (CSP). You cannot simply inject an external engine script or make third-party server calls to evaluate a board position without triggering security blocks.
To solve this, Knight runs entirely offline and locally using a multi-layered Manifest V3 messaging system:

The Core Logic: Powered by an optimized local Stockfish WebAssembly (WASM) engine.
The Bridge: Since Manifest V3 background service workers don't support heavy WASM environments directly in some configurations, the extension utilizes Chrome's Offscreen Document API (and native background workers in Firefox) to run the engine inside an isolated, secure offline process.
The UI Layer: A premium, custom glassmorphic dashboard panel injected directly into the active tab that updates hints instantly on click with zero cooldown.

🧠 Emulating Human-Like Behavior

One of the most interesting parts of this project was moving away from "robotic" engine play. To make the assistant truly feel like a human companion, I implemented mathematical models to simulate organic human flaws and constraints:
Mouse Movement 2.0: Generates smooth Bezier curves with simulated physical hand micro-tremors.
Emulated Fatigue: Thinking times automatically scale and slow down by 2.5% per turn as the game progresses past move 15, mimicking natural mental exhaustion.
Calculated Misclicks: A built-in small percentage chance to click a neighboring square first, pause in hesitation, cancel, and then correct the move.
Opening Book Integration: Automatically fetches and executes the first 14 half-moves smoothly using the Lichess Masters Database.
🎨 Advanced Presets & ELO Scaling

The extension features a mathematically calibrated preset matrix. Users can manually scale the assistant from 1000 to 1500 ELO, which dynamically adjusts engine depth, mistake chances, blunder rates, and average thinking variance in real-time.
There is even a hidden ZXC / Shadow Fiend Mode that overhauls the entire UI into a dark-matte neon-red design, complete with an active animated avatar and audio synchronization.

📂 Source Code & Feedback
The project is completely open-source and licensed under the MIT License. If you are interested in Chrome Extension development, WebAssembly integration, or advanced content script messaging, feel free to check out the codebase!
⭐ Repository: https://github.com/physicalaff/Knight-Chess-Helper
I would highly appreciate your feedback, code reviews, or a ⭐ on GitHub if you find the architecture interesting! What do you think about running heavy WASM engines directly inside browser extensions? Let's discuss in the comments!

DEV Community: physical