Questions, answered plainly

What is Confusables?

A correction engine for one narrow, very common class of English error: a real word used in the place of another real word. its for it's, your for you're, then for than. It finds the wrong word, replaces it with the right one, and leaves everything else exactly as it was written.

Why does this need its own product?

Because a spell checker cannot see these errors. Every word is spelled correctly, so nothing is underlined. They survive every automated check a platform runs, and then they publish: in a support reply, a marketplace listing, a job post, a comment under a brand's own name. They are the errors readers notice and quietly judge.

Spend five minutes in the comments on Facebook, YouTube, Reddit, X or any marketplace listing and you will find then for than, its for it's and lets for let's in the first screen, usually more than once. These are not rare slips by careless writers. They are now common enough that many people have stopped registering them as mistakes at all, which is exactly why nothing catches them: not the writer, not the spell checker, not the platform.

That is the reason this exists. These mistakes reach publication because nothing in the path is looking for them, and the platform is the only party standing at the one moment when something can still be done: when the text is submitted. Before it carries somebody’s name, without lecturing them, and without touching what they meant to say.

Where does it belong in a product?

At the moment text is submitted, server-side in the submit path. It either hands you the corrected text or a list of what it would change.

It is designed for comments and social posts before publication. /v1/check returns each suggestion with its position, confidence and rule, so the author can accept or dismiss it before sharing.

The same API also fits reviews, forum posts, support replies and other short writing. Suggestions keep the person who wrote the text in control, since a correction can still be wrong.

/v1/autocorrect returns the changed text directly. Whether to apply those changes automatically depends on the integration and its tolerance for mistakes.

Which words does it handle?

Twelve rule sets: nine classic confusions, the could of family, and two typo pairs. Three of the twelve ship switched off and are marked below.

The demo on the home page runs all twelve, which is why the three marked ones correct there. “Switched off” is what a fresh self-hosted deployment does before you configure it, not what you are trying out.

• its / it's
• your / you're
• there / their / they're
• then / than
• who's / whose
• lets / let's
• lose / loose
• accept / except
• affect / effect OPT-IN
• could of → could have
• if / of OPT-IN
• form / from OPT-IN

Is it a spell checker?

No. Every word it corrects is already spelled correctly, so a spell checker has nothing to flag. A spell checker works from a dictionary lookup; this works from what the surrounding words can prove.

Is it a grammar checker?

No. It does not flag style, suggest rewrites, comment on tone, or have opinions about the passive voice. It corrects twelve specific confusions and is silent about everything else in your text.

Is it AI? Is there a language model in it?

No. No model, no inference step, no training, no GPU, no per-token cost. It is a deterministic rule engine: the same input produces the same output with the same engine version and configuration, and every correction traces back to the specific evidence that licensed it.

That is a deliberate choice rather than a limitation. In a submit pipeline, being explainable and repeatable seemed more useful than being clever.

Will it change my writing, my style or my voice?

No. It replaces one word with another word. It cannot rewrite a sentence, reorder your clauses, merge or split sentences, swap a word for a smarter synonym, adjust your register, or tidy anything up. There is no code path in it that produces a sentence you did not write.

What exactly is preserved?

Everything except the corrected word. The output is identical to the input apart from the words that changed: the same spacing, the same line breaks, the same punctuation, the same paragraph structure, the same emoji, the same odd formatting you meant to keep.

What happens to capitalization?

A correction inherits the case of the word it replaces, so a sentence keeps its shape.

If my sentence has other mistakes, will it fix those too?

No, and it will not comment on them either. Its a great day isnt it? becomes It's a great day isnt it?. The missing apostrophe in isn't is a typo, not a confusable pair, and this is not a spell checker. Keeping to that narrow remit is part of what makes its behavior predictable, though see the accuracy section on where unattended use is and is not supported by evidence.

Does it prefer American or British English?

Neither. It does not normalize spelling in either direction and will not turn colour into color or the reverse. Both varieties are recognized equally.

What parts of my text does it refuse to look at?

Several regions are protected from correction. Their words are hidden from surrounding correction decisions, except mixed-case identifiers, which remain readable as context:

• Identifiers: obj.lets, lets(x), snake_case, camelCase
• URLs, bare domains and email addresses
• @handles and #hashtags
• Recognized quoted text, straight or curly; ambiguous apostrophes can limit detection
• Text discussing the words themselves: “your and you're”, “its vs it's”
• Code: fenced blocks, inline backticks, <code> and <pre>

Why skip quotations? Those contain mistakes too.

Recognized quotations are protected because changing them can misrepresent what somebody said. For example, she said 'lets go' stays unchanged. Detection is imperfect: a plural possessive apostrophe inside a single-quoted passage can be mistaken for its closing quote, leaving later words unprotected.

How accurate is it, and how do you know?

Preserving correct text is the goal, not a guarantee. A correction can still be wrong, and results depend on the kind of writing. The regression counts below reflect the current build verified on September 19, 2026. The reused prose sweeps were checked again after the latest fixes; synthetic recall was last measured earlier that day at threshold 0.95 with all twelve rules enabled. These are regression measurements, not a fresh accuracy evaluation.

Regression suite	2,063 sentences across 32 corpus files, 1,256 of them correct sentences that must come back unchanged
Automated tests per build	3,949 in total: 988 core tests, 2,739 API unit tests and 222 API integration tests
Technical documentation swept	89 changes in 115,834 sentences · 0.077%
Published fiction swept	83 changes in 42,129 sentences · 0.197%
Introduced it's/its errors restored, swept	2,499 restored of 3,483 · 71.7%
Introduced it's/its errors restored, Evaluation #1 corpus reused	601 restored of 801 · 75.0%

A change rate is not precision. These counts include both useful corrections and wrong changes. The two sweep corpora have informed development, so they are not an independent accuracy test.

The introduced-error test changes possessive its to it's and checks whether the entire original sentence is restored. It measures synthetic errors in one direction, not recall across all twelve rules or naturally occurring mistakes.

Evaluation on informal comments

Evaluation #3, completed September 11, 2026, used 50,000 previously unseen sentences from parenting and academia Stack Exchange comments at threshold 0.95. Confusables changed 273 of 50,000 sentences, or 0.546%. In a manually reviewed sample of 100 changes, 60 were judged correct and 40 damaging: observed precision was 60.0%, with a 95% interval of about 50% to 70%.

A September 19, 2026 pilot on an earlier build using 1,000 unseen comments from cooking, travel and gardening communities changed seven sentences: four useful corrections and three damaging changes. The 57% observed precision has a wide 95% interval of about 25% to 84%. These two evaluations describe earlier builds, not the latest production version. The developer also judged the pilot changes, so this is a preliminary check, not independent annotation or a general social-media accuracy estimate.

Evaluation #3's separate 1,200-sentence probe contained eight natural errors within the supported word pairs. Confusables repaired 3 of 8. That sample is too small for a reliable general recall estimate.

Author review matters. In Evaluation #3, two changes in five were judged damaging. Suggestions that the author can accept or dismiss are the appropriate use for social comments and posts; results on one sample do not guarantee accuracy on your text.

The test suite guards known corrections and preservation cases; it cannot guarantee the absence of regressions. Correct-text cases make up 1,256 of 2,063 corpus rows, about 61%. Checkstyle and SpotBugs run on both Java modules, alongside regression, privacy and bounded-cost tests.

Evaluation methods, source details and limitations are available by request.

Why optimize for precision instead of catching more?

The two failures are not symmetrical. If we fail to fix an error, your user is where they started and probably never notices. If we change a sentence that was already correct, we have altered what somebody published under their own name, which is the more visible problem. The engine is tuned for that difference.

What does it do when the evidence is ambiguous?

The engine tries to leave ambiguous wording unchanged. Its rules recognize many such cases, but they cannot identify every valid reading. Some ambiguous phrases can still receive a wrong suggestion, including form a line after an earlier form typo in the same sentence.

Give me an example of it deliberately doing nothing.

Neither is touched. The fuller list of what it declines to guess at is in the sections below.

What does it miss?

One direction is genuinely harder than the others and we publish the figure rather than let you find it. Turning a written it's back into a possessive its means recognizing the thing being owned, and nouns are an open class, and no list of them is ever complete. Measured on September 19, 2026 at the shipped 0.95 threshold, 2,499 restored of 3,483 · 71.7% of introduced errors were restored exactly across both prose corpora. About seven in ten were caught and three in ten missed. This is synthetic-error recall for one direction, not a general accuracy score.

Other directions also combine structural checks with curated vocabulary, including verb, noun and phrase cues. Missing vocabulary or unsupported sentence structures can cause missed errors or wrong suggestions; the recall figure above measures only the stated it's/its direction.

Could you close that gap?

A part-of-speech tagger might improve coverage, but it would add a model, dependencies and processing cost without guaranteeing correct decisions. Any broader coverage needs evidence that it does not introduce more damaging corrections.

How do I audit a correction I disagree with?

The inspection endpoint answers that where the autocorrect one does not. Every correction comes back with its character offsets, the original word, the suggestion, a confidence score and the rule that fired. Nothing is a black box, because there is no box. The same input produces the same answer with the same engine version and configuration.

What languages does it support?

Currently English only. The current rules and vocabulary cover English. Support for more languages is a long-term goal; no additional language or release date is announced yet.

Will it fix an error outside those twelve pairs?

No. Anything outside them is out of scope by design, not by omission. If your users' most common error is something else, we would be glad to hear about it, though the scope is unlikely to widen quickly.

Are there errors inside the twelve pairs it still will not fix?

Yes, in two groups. The first is genuine ambiguity, where both readings are correct English. The second is anything needing more than a word swap: a lose of power wants “loss”, which is not one of our pairs, and turning it into “loose” would trade one wrong word for another. Whose is at the door? needs a word deleted, and the engine only ever replaces.

Does it handle rich text, HTML or Markdown?

It recognizes and skips code regions and several inline markup constructs, which covers most of what arrives from a comment box. For a structured document format, the usual pattern is to extract text nodes in your own pipeline and pass those. If you let us know your format, we can be specific about what it does with it.

Does it work on very short text? A single fragment?

Yes, though with less to go on. Several rules decide from the words around the token, so a two-word fragment gives them less evidence than a sentence does. Less evidence means the engine is more likely to decline, which is the bias it is built with rather than a promise about every sentence.

Can it run as the user types?

It is fast enough to run on a keystroke debounce, but it has no notion of partial input. It corrects the text you hand it. Half-typed words look like unfinished words, so most integrations run it on blur or on submit.

Does it get better over time?

Behavior changes when a new engine version or configuration is deployed. Regression tests check known corrections and preservation cases; they help detect regressions but cannot rule out every new failure.

How do I call it?

HTTP POST with a JSON body, over two endpoints. One returns the corrected text and a count of what changed; the other returns the corrections as structured data with offsets, so you can render your own review UI, highlight in place, or ask the user to confirm.

What comes back from the inspection endpoint?

Per correction: start and end offsets, the original word, the suggested replacement, a confidence value, and a human-readable reason naming the rule. Plus a per-rule tally and the processing time.

How fast is it, really?

Local regression benchmark on September 19, 2026: three warmup passes followed by five timed passes, on an earlier build, before the latest grammar fixes:

5,001-word document	20 ms median
Per 100 words	≈ 0.40 ms

The fixture uses ten rules, including affect/effect, and applies all returned candidates; it is not an HTTP or hosted-service benchmark. The per-100-word figure is derived from the document timing, not a separately timed short request. Network, hosting and startup time are excluded, and results depend on hardware and input.

How does it scale?

Correction has no persistent user state. Word lists are cached in memory and rate-limit windows are local to each instance. Multiple instances can sit behind a load balancer, but each enforces its own allowance; a shared global limit would need coordination.

What does it need to run?

A container runtime. It is a JVM service on Java 21, ships as a standard container image, and runs comfortably in 512 MB of memory on a single core. No GPU, no accelerator, no external service, no network egress at runtime.

Can I run it inside my own infrastructure, or air-gapped?

Yes, and it is the sensible choice if you have a compliance function. The image makes no outbound calls, so it works with egress blocked entirely.

Can I turn individual rules on or off?

Yes, per rule, through deployment configuration. Three rules already ship switched off by default because they are lower-yield or higher-risk than the rest, and any of the twelve can be disabled the same way.

Can I tune how aggressive it is?

Yes. Every correction carries a confidence value and there is a threshold below which nothing is applied; raising it narrows the output to the corrections backed by the strongest evidence. Today both the threshold and the rule switches are set at deploy time rather than per request. Per-request control is a small change, and we are open to it if that is what your integration needs.

What are the request limits?

Maximum input	50,000 UTF-16 code units (≈ 8,000 words) → 413
Maximum request body	304,096 bytes by default → 413
Rate limit	60 requests/minute per caller → 429
Rate limit, with a key	higher, and metered to you rather than your address
Missing text field	→ 400

Both limits are configurable, and both are defaults for the public demo rather than a ceiling on the engine. The 60 is per caller, and without a key a caller is an IP address, so an integration behind a shared egress shares one allowance. A key fixes that; see question 38. The cap counts UTF-16 code units rather than bytes, so scripts whose characters cost several bytes each get the full allowance: Cyrillic, Greek, Arabic, Hebrew and the common CJK ranges all count as one unit per character. Characters outside the Basic Multilingual Plane cost two, so a body made entirely of emoji reaches the cap at 25,000 of them rather than 50,000.

A 429 carries Retry-After in seconds, and repeats it as retryAfterSeconds in the body, so a caller backing off does not have to guess.

The text field must contain a JSON string. Missing or null text, numbers, booleans, arrays and objects are refused with HTTP 400. An empty string, {"text":""}, is valid and returns unchanged.

Is there authentication? An SDK?

Keys exist, and the public endpoint is still open. Those are not in tension. The demo on this site calls the API from your browser, so any key it carried would be published along with it, and a key everyone can read is not a gate. The endpoint therefore stays open to anonymous callers at the limits in question 37.

What a key buys is a bucket of your own. It travels as X-API-Key, or as a bearer token where that suits the client better, and traffic carrying it is metered as one caller with its own allowance instead of sharing the anonymous ceiling with everyone else on your egress addresses. That matters as soon as you are calling this from a real integration rather than a laptop. A note to [email protected] is enough to ask for one. Whether there is a key, and what allowance it carries, is a conversation about what you are evaluating rather than something issued automatically; there is no signup form, because at this stage every integration starts with that conversation anyway.

A wrong key is refused outright rather than quietly treated as anonymous, so a typo shows up immediately instead of as unexplained rate limiting weeks later. The service can also be configured to refuse anonymous callers entirely, which is what a self-hosted deployment inside your own perimeter would normally do.

There is no SDK. It is JSON over HTTP with a single field in the request, so there is not much for one to do. The API docs have both endpoints with curl, JavaScript and Python examples.

What happens if Confusables is unavailable?

The calling application decides what happens on a timeout. Confusables has no correction queue or automatic retry and does not persist submitted text by default. It does keep operational state, such as cached word lists and in-memory rate-limit windows.

Failing open is the pattern we would suggest: the user's original text goes through unchanged. The corrections are an improvement to text that was going to be published anyway, so a failure to reach us is usually better handled as "no corrections" than as a blocked submission. A short timeout with a fallback to the original text is normally all it takes.

It is worth being a deliberate decision either way, since a call sitting in the critical path without a timeout would turn an outage on our side into one on yours. Self-hosted, most of this goes away, because the engine runs beside your own service and shares its fate.

This section is the privacy notice

Effective September 19, 2026.

It describes what happens to information when you use confusables.io or the hosted API at api.confusables.io. It is written from the running system rather than from a template, and where the software can do something the hosted service does not do, it says so.

What is processed: text you submit to the demo or the API; the network address your request arrives from; ordinary request metadata such as timing and size; the label on an API key, if you use one; and whatever you choose to put in an email if you contact us.

The text you submit

The application does not persist submitted text by default. It reads the request, corrects it, returns the result, and does not save the submitted text by default: there is no database, and no database driver is present on the runtime classpath, which a test asserts on every build.

That is a statement about this application, deliberately. It is not a claim that no byte of your request exists anywhere at any moment, because your text travels over networks and through provider infrastructure we do not control, described below.

Submitted text is not used for training. That is easy to promise here because there is no model. The engine is deterministic rules and word lists, so there is nothing that could learn from your text.

What reaches a log

Normal hosted application logs record a character count, a correction count and a timing, not your text. Writing your text to a log requires a separate explicit setting which the hosted service does not enable, and changing log verbosity alone cannot turn it on. Those are two independent controls on purpose: raising a log level to diagnose something unrelated should not capture anyone's text as a side effect.

A caller that exceeds the rate limit produces a warning line naming the address it came from, so a runaway integration can be identified. If you present an API key, the label on that key appears instead, never the key itself.

Your network address

The service temporarily processes the address a request arrives from, in memory, to enforce the rate limit and to refuse abusive traffic. It is not written to an application database. As noted above, an address can appear in a warning log when a caller exceeds the limit.

Providers in the request path

Two providers sit in the hosted request path itself, named because a description of what our application does would mislead without them.

Cloudflare	terminates the public connection for this site and the API
Render	runs the application container

Both operate infrastructure used to deliver the service and may process connection and request information as part of providing it, under their own terms and logging, which we do not control and will not characterize on their behalf.

Separately, loading a page in your browser reaches further than that. Cloudflare injects a performance-measurement beacon and a bot-detection script into these pages. Those come with the platform rather than from our source, and we are telling you because a page that claimed to carry no third-party code would be wrong. This site also loads its typefaces from Google Fonts, so Google receives the request for those files, including your address and browser.

Beyond that, we do not use advertising services, behavioral analytics, tracking pixels, social widgets, or anything that follows you to other sites.

Cookies, and tracking across sites

The application sets no cookies, and a plain page load in a clean browser produced none. Cloudflare's protection can set a cookie of its own in some circumstances, which is why this says what was observed rather than promising a category that is not entirely ours to promise.

Do Not Track. We do not follow your activity across other websites for advertising or profiling, so a browser Do Not Track signal does not change anything we do. We cannot make that promise on behalf of the providers above.

We do not sell personal information, and we do not use correspondence for advertising or marketing.

If you email us

Contact is an email address, not a form. The demo box is the only field on this site where you submit content directly to us; everything else that reaches us in the course of serving a page is described above. Writing to us means we receive whatever you chose to include, typically your address, your name and your message, and we use it to answer you and to manage that conversation.

There is no automatic deletion schedule. Correspondence is kept while it is useful to the conversation or to related follow-up. Saying that plainly is more useful than naming a tidy retention period nobody enforces.

There are no user accounts or saved correction histories here. Operational logs may contain a network address or API-key label, and correspondence may contain information you sent us. Questions about access, correction or deletion of information we hold can go to contact; provider handling is described above.

Running it yourself, and changes to this notice

Self-hosted, your text never reaches us. The container runs inside your own network, the engine makes no outbound call while correcting, and there is no callback or telemetry. Cloudflare and Render are not in that path and neither are we. The software behavior above still applies: text logging is still a separate setting that verbosity alone cannot enable, and the surrounding infrastructure and logs become yours to decide about.

If this notice changes materially, the revised version is posted here with a new effective date. Questions about any of it go to the same place as everything else: contact.

Why not just call a language model?

That is a reasonable option for some jobs. But ask one to fix its and it will often hand back a better sentence than the one it was given: smoother, more correct, and not what your user wrote. It also costs per call, adds network latency, and gives different answers to the same input on different days, which makes an incident hard to reproduce and a correction hard to defend.

And there is a product reason on top of the engineering one. People resent having their words rewritten. A user who finds their comment reworded, even into better English, reads it as the platform putting words in their mouth, and that is a complaint rather than a feature. Correcting only the misused word avoids most of that: few people defend then where they meant than, and nothing else about the sentence has changed.

This handles a narrow set of word confusions without model inference or per-token inference costs. Running it still costs whatever the infrastructure under it costs, wherever it runs. The engine does not generate or rewrite sentences.

How is this different from a writing assistant?

Confusables is an API a platform integrates into its own interface. It supplies narrow word-level suggestions rather than a complete writing editor. For social comments and posts, the platform can show those suggestions before publication and let the author decide.

Can we run it alongside what we already have?

Yes, and they compose cleanly because the remit is so narrow. It corrects twelve confusions and stays silent otherwise, so it will not fight another tool over style, tone or phrasing.

Why trust a small engine over a large vendor?

One practical reason: you can check it before committing to it. Because it is deterministic, running your own text through gives you exactly what it would have done to a year of your real traffic, and the same answer every time. That is harder to do with a system whose output varies.

Is it open source?

No. It is proprietary software, all rights reserved. The English vocabulary inside it is expressly not claimed as property. The language belongs to everybody; the engine does not.

Is Confusables commercially available?

Not yet. Confusables is in development. There is nothing to buy, no license to sign and no billing, and we are not putting a price on something that is not finished.

What exists is open for evaluation. The public API takes no account and no key, the demo on the home page runs the same engine rather than a canned recording, and the self-hosted image is available to discuss for evaluation. If you want to talk about using it, [email protected] reaches us.

Who runs the servers?

It depends which of the two you run.

Self-hosted: you do. You pull one container image into your own cloud and run it like any other service. There is no callback to us, no license server, no phone-home, and nothing of yours crosses our network, so availability is yours, and it is as good as the platform you already trust with everything else.

It runs anywhere that runs containers, which today is everywhere: AWS (App Runner, ECS/Fargate, EKS), Google Cloud Run, Azure Container Apps, or plain Docker on one virtual machine. It is a standard image with no database, no queue, no external dependency and no GPU, so whichever cloud your team already runs is the right one. If you have no existing preference, the fully managed container services are the least work: Google Cloud Run and AWS App Runner both take an image and a port.

Hosted: we do. You call the endpoint. That is the public evaluation endpoint described in the API docs, which carries no availability commitment.

How can I evaluate it?

The public API is open for evaluation. It takes no account and no key, so you can call both endpoints right now against the limits in question 37 without asking us for anything, and the demo on the home page is the same engine rather than a canned recording.

If those limits are too small for what you are trying to find out, an email describing the evaluation is enough to discuss a key. We are not issuing them automatically and we are not promising a particular allowance, because a submit-time filter is not something anybody can evaluate properly in two weeks and we would rather agree on what you need than guess at it. What we would want in exchange is to hear what it got wrong on your text.

For the self-hosted image, we would rather work out an evaluation that fits what you need to find out. [email protected] reaches us.