How often does your keyboard break a word you typed correctly?

Explainer · Published 10 November 2026 · 6 min read

Keyboards are judged by the typos they fix. The number you actually feel is the other one: how often a word you spelled right gets rewritten. I have never seen a keyboard maker publish it, so here is how I measure it for mine, with the charts, the trade-offs and the bugs in my own measurement.

Two numbers that pull against each other

Lower the bar for a correction and you catch more slips. You also overwrite more words the keyboard does not know: names, slang, a word from your other language. A keyboard tuned on “typos fixed” alone drifts towards rewriting, because every lucky rewrite counts and every unlucky one is invisible to that metric.

Here is the trade-off in one real experiment. On recorded phone taps¹, I tried a simple rule: when the typed word is a valid word but the sentence model prefers another candidate by t bits, replace it.

A missed typo costs you a retype. A correct word rewritten costs the keyboard its place on your phone. So both numbers go in every report, and a change that moves one has to say what it did to the other.

How it is measured

For each language, the test text is a sample taken every n-th line through every corpus the language is built from, and those lines are kept out of the word list and the model. It is typed back through the keyboard’s own engine, keystroke by keystroke, with the sentence model on and English enabled alongside, on a dictionary that has learned nothing about the user.

“Typos made worse” is the one people forget: the keyboard takes your wrong word and turns it into a different wrong word. It is 1.7–5.5 % here.

Forty languages on one chart

The spread is real, not noise. Languages with heavy inflection have many correct words one letter apart, so a slip lands on another valid word and the keyboard cannot tell. My own language sits near the bottom of my own table.

Moving the curve instead of sliding along it

Tuning a threshold only moves you along the trade-off. To get more fixes and fewer breaks, the decision itself has to get better. The rule engine proposes ranked candidates; a small learned corrector (a two-layer network) then weighs them on relative features (about 26 of them: edit cost, word frequency, the context score, the sentence model’s score, each also relative to the best option and to the typed word) and applies its pick only if it beats “keep what was typed” by a margin. It is trained on mistyped and correct words alike, so it learns when to leave things alone.

Without the sentence model’s scores as an input the same corrector is worse than the rules, so the model is the part doing the work.

Where it still fails: short words

On real fingers rather than synthetic slips, the residual errors are concentrated in one place.

The reason: a slipped short word is nearly always another real word. Of mistouched words of one to three letters, 78 % came out as a string the word list holds, against 13 % for longer words. The keyboard’s rule is to keep a valid word, and that rule is right for camelCase and wrong for ib meaning in. That is where the threshold experiment above came from, and why the next step uses where the finger landed, not just the model.

Three times my own number was wrong

1. The test set was the training set’s tail

At first the held-out text was the last 2,000 lines of each language’s main corpus. That corpus was also the training data (almost a quarter of its English sentences mention someone called Tom). And a corpus is concatenated documents, so its last 2,000 lines are mostly its last document. In one language, that document was a subtitle release typed without any accents. The keyboard restored them correctly, and the test scored every restoration as a false correction.

2. The fixture was wrong, not the engine

Two words in a test list were missing their accents. The keyboard restored them and every run counted two misses. Now the first thing I check when a number looks bad is the test data.

3. A test that could not fail

Three “nothing was learned here” assertions passed against an engine whose learning was switched off. Every negative test now has a positive control beside it: the same setup, a case where the thing should happen, which fails if the setup is broken.

And the recurring small version: twice in one day, a handful of hand-written examples gave a number that a real corpus then contradicted, once by more than ten times. Under about fifty samples, I say so next to the number.

Every bug becomes a line

A bug found on a phone becomes a row in a plain TSV: the text before, the exact keystrokes, the exact text that must come out, and where the report came from. All 940 rows across 40 languages replay on every test run.

lang  before  typed      expected   mode  status  source
en    sorry   runing     running    live  ok      2026-09-23: a stray after the last word read `run in`
en    -       camelCase  camelCase  live  ok      the stray split cut an identifier as `came case`

Many rows say what must not change. Known bugs go in as open (44 of them now): expected to fail, and the test fails the day one starts passing, so nothing gets fixed by accident without being noticed.

What these numbers do not tell you

• Real typing has more than one error per word, and errors cluster. The real-tap set is English only and lab copy-typing.
• It is my keyboard, measured by me. I could not find a comparable published number for Apple’s keyboard, Gboard or SwiftKey, so there is no competitor column here. I would love to see one.

Language figures from Pilcrow’s scorecard, measured 12 October 2026 on all 40 languages; the corrector and word-length figures from offline runs of October and November 2026. Questions or corrections: info@pilcrowtype.com.

Sources

1. Keith Vertanen and Per Ola Kristensson, A Dataset of Noisy Typing on QWERTY Keyboards, IUI 2023 (CC BY 4.0): recorded touch points on phone keyboards, used here for the threshold and word-length charts.