One of the most common questions we get from users who just installed Linguix is: how does this actually work? They type something in Gmail, a teal underline appears, they click it, a suggestion appears. The mechanics feel invisible, which is the goal. But the question of what is happening underneath is a reasonable one, and the answer is more interesting than it might appear.
The problem with inline browser extensions
Building a writing tool that works inside Gmail, Google Docs, and the rest of the web involves a core challenge: every web application stores and renders text differently. Gmail uses its own rich text editor. Google Docs uses a custom canvas rendering engine. Notion has its own block-based structure. Slack renders messages inside React components. None of these expose a standard API that a browser extension can call to "get the text the user is typing."
Early browser extensions worked around this by monitoring clipboard content or asking users to copy text into a separate input field. This is why the copy-paste workflow became so common in this category of tool: it was the technically straightforward path that avoided the problem of interfacing with arbitrary web application editors.
We did not want to take that path. The copy-paste workflow breaks the writer's flow, and it means the tool only sees text at the moment of copying rather than as it is being written. For a correction tool, inline operation is the whole point.
How the extension attaches to a text field
When you open Gmail or Google Docs in Chrome with Linguix installed, the extension injects a small content script into the page. This script uses browser-standard methods to identify active text input regions: elements where the user is currently typing or where text editing occurs. For most web applications, this includes standard HTML input and textarea elements, contenteditable divs, and elements with ARIA roles indicating editable content.
The script attaches event listeners to these elements that fire when the user types. The events capture keystrokes and, at intervals, the current state of the text in the editable region. This text is sent to Linguix's analysis engine, which processes it and returns a set of annotated positions indicating where suggestions exist.
The annotations are then used to inject the visual underlines into the text display, overlaid on the original text rendering. This is where the implementation gets more technically involved, because different web applications render text differently and the visual overlay approach that works in a contenteditable div does not work the same way in Google Docs' custom canvas renderer.
Google Docs: the specific challenge
Google Docs renders text on an HTML5 canvas element rather than in standard DOM text nodes. This is what allows Docs to behave like a native desktop application in a browser: the rendering is fast and fully controlled by Google. It also means that standard DOM-based approaches to injecting underlines do not work, because there is no underlying DOM text structure to attach them to.
The approach we use for Docs involves capturing the text content through the DOM structure that Docs does expose for accessibility purposes, and rendering our suggestion indicators as a positioned overlay above the canvas. The overlay is synchronized with the Docs rendering so that underlines appear at the correct visual position relative to the text. When the document scrolls or text reflows, the overlay updates accordingly.
This approach is more brittle than standard DOM injection because it depends on Docs exposing its text content in a way that can be read and on the canvas rendering behaving consistently. When Google updates Docs, there is always a risk of breakage at this layer. Maintaining the Docs integration requires ongoing attention in ways that the Gmail integration does not.
Analysis latency and the user experience
A writing assistance tool that introduces noticeable lag is worse than no tool at all. If the underline appears two seconds after you stop typing, you have already moved on. The feedback loop needs to be fast enough that suggestions feel like part of the typing experience rather than an interruption of it.
We handle this in two ways. First, we batch analysis: rather than sending a request to the analysis engine on every keystroke, we wait for a short pause in typing before sending. This reduces the number of requests and avoids sending partial sentences or words for analysis. Second, we use a tiered analysis approach where fast, lightweight grammar checks run locally in the extension and are available within a few hundred milliseconds, while more compute-intensive style and tone analysis runs server-side and arrives slightly later. The user sees the fast results first and the detailed results follow.
The local analysis layer handles the highest-confidence grammar patterns: subject-verb agreement, article errors, clear preposition errors. These are the cases where speed matters most because writers typically want immediate feedback on errors they just introduced. Style suggestions, which require more context and more compute, can tolerate a slightly longer delay because they are more likely to be reviewed after a draft is complete rather than as it is being written.
Privacy: what text is processed and where
Text processing in a writing tool raises privacy questions that deserve a direct answer. When you type in Gmail with Linguix active, the text you type is sent to Linguix's analysis service for processing. The text is used to generate suggestions and is not stored on our servers after that processing is complete. We do not retain the content of messages, emails, or documents beyond the processing window required to return suggestions.
The extension does not send text unless the user has the Linguix extension active. Users can pause the extension for any page or domain from the extension's popup. We do not process text on banking, health, or financial sites by default, and users can add any domain to an exclusion list.
We understand that for users who write confidential content, even processing without retention may not be acceptable. This is a real tradeoff in the design of any inline writing tool. We try to be transparent about what the processing involves so that users can make an informed decision about where they use the tool.
Where it works and where it does not
Linguix works in any standard contenteditable or textarea element in Chrome. Gmail and Google Docs are the most tested platforms, but the extension works in LinkedIn's message composer, Notion's editor, Slack's message input, and most other web-based text editors that use standard HTML editing patterns.
Platforms that use custom non-standard editors or that block content script injection may not work fully. PDF editing tools, embedded webviews in desktop applications, and some proprietary enterprise collaboration platforms fall in this category. We flag when the extension cannot attach to a text field and explain why, rather than silently failing to provide suggestions.
The goal is that the extension should feel like a reliable partner in the writing process: present when useful, not intrusive when not needed, and honest about its limits.