Gemini API vs. custom NLP for browser spell checking

Spell checking looks simple until a correction changes what a sentence means. A short, narrow checker can catch a misspelling quickly. A broader language model may be better placed to judge which word fits the surrounding sentence. Neither approach wins every case, and “AI” alone is not a useful quality test.

TypoGuard describes itself as a Chrome extension that corrects text in supported web fields as people type. Its site says the correction technology is powered by Gemini AI through Google’s API. That is one concrete example of an extension choosing a general-purpose model service rather than relying only on a custom, specialized spelling pipeline. It does not, by itself, establish how the extension handles every class of error or how its results compare with alternatives.

Where context helps

A spell checker can flag a word that is absent from its dictionary or looks close to a known word. But spelling is often a sentence-level question. “Their” and “there,” for example, are both valid words. A checker that considers only the token may not have enough information to select the intended one. The same issue appears with grammatical agreement, missing words and corrections whose suitability depends on nearby text.

A general-purpose language model can use more of the surrounding passage when proposing an edit. That can help with ambiguous cases and with corrections that involve more than swapping one misspelled word. It also creates a risk: a system that is asked to improve text may change wording that was already correct, or make an edit that sounds plausible but shifts the writer’s meaning. Context awareness is useful only when the correction stays within the writer’s intent.

For an in-field checker, the practical test is not whether a model can produce polished prose in a demonstration. It is whether it fixes the errors users actually make, leaves correct text alone, and returns a suggestion while the writer is still composing. The latency trade-off deserves its own measurement; our earlier look at the latency budget for browser correction covers why a late suggestion can miss its purpose.

What a custom NLP checker can do well

“Custom NLP” covers many designs, not one standard product. A team might combine dictionaries, edit-distance rules, grammar patterns, language-specific resources or a smaller trained model. These components can be tuned for a known vocabulary and a defined set of errors. They may also be easier to inspect and test in narrow, predictable cases.

A focused checker can avoid asking a broad model to interpret every sentence. Depending on its design, some of its work can run locally, which can reduce dependence on a remote service. But local execution is not automatic: model size, language coverage, browser constraints and the chosen architecture all matter. A rules-based checker can also miss context that falls outside the rules its developers anticipated. “Custom” does not mean accurate by default, any more than “LLM” does.

The engineering bill is different

An API-based model shifts part of the computation to a remote service. That can spare an extension team from building and maintaining its own correction model, but it introduces a network request and a dependency on the API. Response time can vary, and the team must understand service availability, usage limits and costs. For TypoGuard, the available product information identifies Gemini through Google’s API but does not spell out those operational details, so they should be verified rather than assumed.

A custom pipeline has a different burden. Its builders must choose and maintain language resources, test edge cases, and decide how to update rules or models as writing patterns change. If it runs locally, they must also account for the extension’s resource budget and the user’s device. A hybrid design is possible too: a narrow local pass could handle predictable errors while a remote model handles harder context. Whether that is worthwhile depends on product requirements, not on a general rule that one architecture is superior.

How to choose for a browser extension

Test both approaches on representative text from the fields where people write: short messages, longer emails, multilingual text and domain-specific terms. Measure at least four things: corrections that are right, incorrect changes, response time, and the cost of serving real usage. Include text with names, jargon and valid but uncommon words. A checker that fixes common typos but repeatedly alters names may create more review work than it saves.

Then examine what happens to submitted text. With an API-based design, check the provider’s data-handling terms and the extension’s disclosures. Do not infer privacy behavior from the model name or from the fact that a tool runs in a browser. For a local design, check what is stored on the device and how updates are delivered. These are architecture questions, not claims about any one provider.

For users, the decision is simpler: try the tool on your own writing and inspect suggestions before accepting them. TypoGuard offers a free plan, but the plan alone cannot answer whether its Gemini-based corrections suit a particular workflow. For builders, the key comparison is not “LLM versus NLP” as a slogan. It is whether context improves the errors that matter enough to justify the service, latency and data-handling trade-offs.