Guide

Spellchecking text that cannot leave the browser

Some applications cannot send what their users type to a third party. A clinician's notes. A caseworker's report. A lawyer's draft. A student record. If that is your product, spellcheck stops being a small feature and becomes a procurement question.

There are four ways to answer it. Sqwig is the fourth, so read the first three knowing that. Here is what each one actually costs.

Leave the browser's own spellcheck on

Free, works today, and for a comment box it is fine. What you give up:

• You cannot read it. Nothing reports which words were flagged or what the suggestions were. If your product needs to know the text has errors, to show a count or to gate a submit, the browser cannot tell you.
• You cannot teach it. "Add to dictionary" writes to that user's profile, on that device. Your product's own vocabulary stays flagged for every user until each of them fixes it by hand, on every machine they use.
• It is not one behavior. The dictionary belongs to the platform, so the same paragraph flags different words on macOS and on Windows. A bug report can be accurate on the reporter's machine and wrong on yours.

Most rich text editors set spellcheck="false" for exactly these reasons, which is usually why the box in your application has no underlines at all.

Buy the vendor's hosted checker

Full control, and the common arrangement. The text is posted to a service as the user types.

That is a sentence in your privacy policy, an entry on your subprocessor list, and an answer you owe in every security review. For a comment box nobody minds. For the applications above it is the sentence that stops the purchase, which is why plenty of serious products ship a text box with no spellcheck at all.

Host the checker yourself

Keeps the text inside your boundary and hands you a component to operate: version upgrades, base image rebuilds, capacity, monitoring, and an on-call story for something whose entire job is drawing red underlines.

It is a small service. Small services are not free. They are the ones nobody remembers until they break.

Run the dictionary on the device

Nothing to disclose, because nothing is transmitted. Nothing to operate, because there is no service. This is what Sqwig does, on every plan including the free one, and two things make it harder than it sounds.

The word list is large. A usable English dictionary is a lot of terms, and shipping all of them before the first check means a slow start on a slow connection. Loading the common words first and the long tail afterwards puts the first underline on screen quickly without giving up coverage later.

Building the index blocks the page. Preparing a dictionary for fast lookup is real work, and on the main thread it freezes the page while someone is trying to type. Ours did: an early build spent close to twenty seconds of blocked main thread on a mobile profile. Moving the engine into a Web Worker took that to a fraction of a second, because the page stopped waiting on it.

What it buys, and what it costs

It buys an empty answer to "where does the text go", an editor that keeps working offline, and a dictionary you control, so your product's own vocabulary is correct for every user on first load instead of something each of them adds by hand.

It costs a download and it costs languages. The dictionary is bytes your page did not carry before, about 381KB over the wire for the core word list. And a dictionary on the device covers the languages it ships with, where a service can offer a longer list. Sqwig ships US English.