On August 11, 2025, Microsoft retired the Bing Spell Check API along with the rest of the Bing Search APIs. A year later, the search traffic hasn't retired at all — developers still type "bing spell check api" into Google, land on the retired documentation, and start looking for a replacement. Microsoft Learn's own Q&A thread ("Replacement for Bing Spell Check? Discontinued August 11th") and a well-traveled Reddit post are still the top results for the query, which tells you how thin the good answers are.

This guide covers what Bing Spell Check actually did, what Microsoft suggests instead (and why it often doesn't fit), the realistic alternatives in 2026, and a concrete migration of a Bing client to a proofreading API.

A disclosure up front: we build AmberPen, a neural proofreading API, so we have a stake in this comparison. The code and the checklist below are written to be useful whether or not you choose us.

What Bing Spell Check actually gave you

It's worth being precise, because "spell check" undersold it. The endpoint was https://api.bing.microsoft.com/v7.0/spellcheck, authenticated with an Ocp-Apim-Subscription-Key header, and it took three parameters: text, mode (proof or spell), and mkt (a market code like en-US). Mode spell used dictionary lookups with optional pre-context for accuracy; mode proof applied contextual rules — it caught things like "their" vs. "there" in some cases and was the mode most production apps used.

The response was a list of flagged tokens:

{
	"flaggedTokens": [
		{
			"offset": 5,
			"token": "sentnce",
			"type": "UnknownToken",
			"suggestions": [{ "suggestion": "sentence", "score": 0.92 }]
		}
	]
}

That shape — an offset, the offending token, ranked suggestions — is exactly what an editor integration needs. You could underline from offset to offset + len(token) and offer replacements. It was cheap, it supported around a dozen languages in proof mode, and it was fast enough for as-you-type checking. Its weaknesses were a per-request text limit that broke long documents into awkward chunks, suggestions without categories or explanations, and corrections that were fundamentally a token-substitution model rather than real grammar correction.

What Microsoft suggests instead

Microsoft's migration guidance points at Azure AI services. In practice, the recommendation lands on LLM-based correction — prompt an Azure OpenAI deployment with "fix the spelling in this text" — or on Azure AI Content Safety's text correction capability, which is narrower than what Bing offered.

Two problems with the LLM route, both of which come up in the migration threads:

  1. It breaks the edit model. An LLM returns corrected text, not structured edits. You no longer know which ranges changed, so underlining, suggestion cards, and accept/reject UX all have to be rebuilt around diffing — and diffs of LLM output are noisy.
  2. It changes the cost and latency profile by an order of magnitude. A general-purpose model processing whole documents per check is slower per keystroke and bills per token in both directions. For a spell-check-shaped problem, you're paying for a much bigger hammer.

If your use of Bing was "flag the typos in this string," an LLM can do it. If your use was "power the red underlines in my editor," the retirement is an opportunity to move to a purpose-built proofreading API instead of a general model.

The realistic alternatives in 2026

Here's the honest landscape, with the trade-offs that matter for a migration:

Service Edit format Grammar + spelling Structured edits Self-host option Pricing model
AmberPen Offset edits with replacements and categories Yes Yes No Base plan + per-character overage
Sapling Offset edits Yes Yes No Per-seat / volume tiers
LanguageTool Offset matches with replacements Yes Yes Yes Free self-host or per-user premium
Harper Offsets (Rust engine) Mostly rules Yes Yes Open source (AGPL)
Azure OpenAI / LLM prompt Corrected text Yes No (diff required) No Per token
Perfect Tense / Ginger Varies Partial Partial No Flat plans, aging platforms

A few notes on choosing:

  • If you self-hosted nothing and just need the endpoint replaced, any of the first three work. LanguageTool has the deepest language coverage; Sapling and AmberPen are the closer analogues to Bing's "one POST, corrections out" ergonomics.
  • If you were on Bing for price, LanguageTool's premium tiers or a self-hosted instance are the cheap exits; Harper is free but English-only and rule-based, so correction quality plateaus below the neural services.
  • If you need as-you-type UX, latency and edit format matter more than headline features. You want sub-200 ms median responses and structured edits you can map onto editor positions — the same properties that made Bing pleasant to integrate.
  • If privacy pushed you toward Bing's enterprise terms, check whether a vendor trains on your text and whether retention can be disabled; that's a bigger differentiator now than raw accuracy on public benchmarks.

Migrating: a Bing client in fifteen lines

The typical Bing client built the query string, set the subscription key header, and walked flaggedTokens. Here's a representative before/after in TypeScript.

Before — Bing Spell Check:

const params = new URLSearchParams({ text, mode: "proof", mkt: "en-US" });
const response = await fetch(
	`https://api.bing.microsoft.com/v7.0/spellcheck?${params}`,
	{ headers: { "Ocp-Apim-Subscription-Key": process.env.BING_KEY! } },
);
const { flaggedTokens } = await response.json();

for (const token of flaggedTokens) {
	underline(token.offset, token.offset + token.token.length);
	suggest(token.suggestions[0]?.suggestion);
}

After — AmberPen:

import { createAmberPenClient } from "@amber-pen/sdk";

const amberPen = createAmberPenClient({ apiKey: process.env.AMBERPEN_KEY! });
const { edits } = await amberPen.proofread({ text });

for (const edit of edits) {
	underline(edit.start, edit.end);
	suggest(edit.replacement);
}

The shape maps almost one-to-one: flaggedTokens[].offset → edits[].start, token → original, suggestions[0].suggestion → replacement. Three differences you'll notice immediately:

  1. Edits are complete. Every edit carries start, end, original, and replacement, so you can apply all corrections programmatically (applyEdits(text, edits) in the SDK) instead of trusting a top suggestion per token.
  2. Corrections are grammatical, not just orthographic. "The new settings works across every workspace" gets a subject-verb fix, not just spell-level flags. Bing's proof mode did a little of this; a neural proofreader does it as the default.
  3. There's no market code. You don't pass mkt; the model handles English variants and, critically, you can pass dictionary and properNouns arrays per request so product terms ("cachebuster", your brand names) stop getting "corrected." Bing had no equivalent, and it's the most common reason spell-check integrations annoy users.

The raw HTTP call is just as simple if you don't want the SDK:

curl https://api.amberpen.dev/proofread \
  -H "authorization: Bearer $AMBERPEN_KEY" \
  -H "content-type: application/json" \
  -d '{ "text": "This are a sentnce by AmberPen.", "properNouns": ["AmberPen"] }'

The long-document wrinkle

One thing Bing handled badly and many migrations re-create badly: length limits. Bing's practical ceiling forced you to chunk text yourself, and naive chunking broke context at boundaries (a misspelling that depends on a word two sentences earlier is invisible inside a chunk).

The modern answer is incremental checking with streaming. Instead of re-sending the whole document on every pause, you send a stable textId, and the server streams back only edits for the chunks that changed:

const edits = [];
for await (const batch of amberPen.proofreadStream({ text, textId, mode: "correct" })) {
	edits.push(...batch);
}

The first call checks everything; later calls on the same textId check only what changed and carry cached edits for untouched text into the full-document result. For an editor integration this is the difference between a bill that scales with keystrokes and a bill that scales with actual writing.

Choosing your exit

A short decision tree, a year after the retirement:

  • "I need it working this week, English, in my editor" → a neural proofreading API with structured edits (AmberPen, Sapling). Port your flaggedTokens loop as above.
  • "I need 25 languages and I'm fine with rule-based quality" → LanguageTool, managed or self-hosted.
  • "I need offline / air-gapped / free" → Harper, accepting the quality ceiling.
  • "I already pay for Azure OpenAI and this is a batch job" → an LLM prompt is defensible; just don't build interactive UX on it.

Whichever direction you go, the retirement is a forcing function to fix the two things Bing never gave you: real grammar correction and per-request vocabulary control. Don't settle for a like-for-like spell checker — the replacement can be strictly better than what it replaced.

If you want to test AmberPen against your old Bing traffic, the Starter plan costs €5 per month with 500K characters included, then €9 per million, and the API docs cover streaming, incremental checking, and custom dictionaries. See how we compare on public benchmarks, or read the detailed LanguageTool and Harper comparisons.