LocalType and Gboard: an editor-only benchmark

I wanted a comparison I could rerun in an afternoon and defend. Two days of trying to read Gboard’s suggestion strip and drive its settings screens had produced no complete result, so on October 10, 2026 I threw that out and measured only what each keyboard leaves in the editor. This page is the method, every cell with its interval, and what it does not show. The one-table card summarises it.

Method

A test editor app of my own, with a native text field and a web text box, is installed on a Pixel 9a and a Pixel 10 (both on API 37). A host script selects a keyboard, resets it once through its own supported controls (LocalType’s Forget learned words and Clear log; Gboard’s Delete learned words and personal dictionary clear), then types 100 invented sentences into the field by injected touches at 60 ms per key, one block per keyboard, block order alternating. Two cells on the Pixel 10 took a second block, noted under the tables. Each sentence is a short invented frame followed by four seeded common words of five to eight letters drawn from ranks 500 to 5,000 of the frequency list: two with a planted typo (a substituted, transposed, missing or doubled letter) and two clean. Nothing is read from either suggestion strip. After each sentence the editor’s text is exported and the fixture verifies the phone is restored.

Taps land with a seeded Gaussian spread around each key’s center. The spread is a fraction of the key pitch, the centre-to-centre distance along the top row, which both keyboards share at about 107 px on these screens: 0.13, 0.22 and 0.31 of it, or 14, 23.5 and 33 px. At 14 px one tap in a thousand lands off its key. A sentence keeps one noise seed at every spread, so its taps at the wider spreads are the same draws scaled up. Every noisy tap is held inside the keyboard’s own key area: a stray tap can hit a neighbouring letter or a control key such as shift or delete, which is the keyboard’s to handle, but never the suggestion strip or the screen beyond the keys. The results below are from one frozen run of both keyboards on October 11. That run also typed every sentence at exact key centers; those rows are withdrawn, for the reason given under them.

Scoring aligns the editor’s words to the intended words. A planted typo is corrected, unchanged or wrong; a clean word is preserved or changed. A typo that was corrected and also capitalised counts as corrected, and a clean word that was only capitalised is not counted as damage. Under spread each word is judged against the keys its own taps landed on: a typo left as planted or as landed is unchanged, and a clean word left exactly as its taps landed is unrepaired noise rather than damage. A word with a tap that left the letters and the space bar altogether is judged against the intended taps and counted. Character error rate is Levenshtein distance over the target length. Differences are LocalType minus Gboard with a 95% paired bootstrap by sentence; the phones are never pooled. Every table on this page is generated from the scorer’s summaries.

Correction

With taps scattered 14 px, LocalType corrected 134 of 200 planted typos and Gboard 103. At 23.5 px it was 127 against 106, in the native field and much the same in the web text box. At 33 px it was 110 against 100, a difference the interval does not separate from zero. Among the clean words that could be matched, LocalType changed none through 23.5 px and four at 33 px, against Gboard’s five; at 23.5 px four clean words per keyboard could not be matched at all, because a stray tap hit delete and removed a space, the same two sentences for both. LocalType made more wrong corrections at 14 px (15 against 10) and fewer at 23.5 px (15 against 21) and 33 px (26 against 38); each wrong correction is a replacement by another word, such as out for a mistyped route. Neither keyboard’s correction rate falls off a cliff during a block; both drift a little with the order of the sentences, together.

Equal pixels is nearly equal difficulty here. At 33 px 12% of LocalType’s letter taps and 11% of Gboard’s landed outside the key they aimed at; at 23.5 px 3% of each. Gboard’s rows are taller, 167 px against 142, so the same scatter leaves its rows slightly less often. Thirteen of the 200 planted typos turned out to be words themselves (witch for switch, phone for phones); they stay in the totals, and neither keyboard corrects them. On the other 187, at 14 px, LocalType corrected 72% and Gboard 55%. Words with a tap outside the letters and the space bar are judged against the intended taps and counted: 9 and 3 at 23.5 px, 42 and 10 at 33 px, LocalType and Gboard, of 400.

The counts for the two phones agree within two words in every cell. LocalType’s text was identical on both; Gboard’s differed in one to four sentences per cell. On the Pixel 10 the two web cells stopped once each, on the test editor’s own check that LocalType’s suggestions had appeared before a case may be scored, and were finished in a second block after a second reset. So 28 and 34 of LocalType’s sentences in those cells were typed early in a fresh block while Gboard’s came from its first block. The Pixel 9a, shown above, took one block per cell.

Exact key centers: withdrawn

The first version of this page led with taps at exact key centers, where LocalType corrected 133 of 200 planted typos and Gboard 2 in the native field and 89 in the web text box. Those rows do not measure Gboard, and I have withdrawn them. Gboard changes behaviour when every tap lands on the exact center of its key, which no person’s taps do. It corrects and completes normally for about the first dozen words of a block, then stops correcting in the native field and stops offering completions. With taps scattered by as little as 9 px it does not do this. In three separate runs with different sentence orders, on both phones, every one of Gboard’s native key-center corrections came in the first three sentences of its block and none in the ninety-seven after. I found it on October 11 while probing the suggestion strip, traced it with four short diagnostic runs, and did not find it in any cell with scattered taps. I do not know why Gboard does it. The web key-center row shows no such cliff. I withdraw it with the native one because its taps were the same, and Gboard corrects more in that field with scatter (106) than without (89). LocalType’s own key-center result, 133 of 200, is unaffected and matches its 134 at 14 px. One caution about my own wording: every probe used taps with no scatter at all, at the center. I have not tried taps that all land on one off-center point, so I cannot say whether it is the centering or the absence of any scatter that Gboard reacts to.

Next-word prediction

A separate probe reads both suggestion strips and taps nothing. It uses 150 phrases from the MacKenzie and Soukoreff set, which people wrote; I did not write test sentences myself, because Chime was trained mostly on machine-written dialogue and my sentences would favour it. Each phrase supplies one target word of three to eight letters, and no word is a target twice. The words before the target are already in the editor, the same for both keyboards. The probe reads the strip, types the target one letter at a time with taps scattered about 9 px, and reads the strip again a second after each letter. Each keyboard is reset once before its block.

The two are at parity. The next-word offer is right for about one target in ten on either keyboard, a difference of +0.007 [−0.04, +0.053]. Once typing starts LocalType reaches the target a little sooner, and the difference in potential savings per word is +0.028 [0.000, +0.056], on the edge of its interval. Potential savings assume the word is tapped the moment it appears, so they are a ceiling and not what anyone saves. One design difference tilts this toward LocalType: while a word is being typed Gboard uses one of its three slots to echo the letters typed, so it shows two suggestions to LocalType’s three. Both strips were steady across their blocks.

This does not show that either keyboard predicts better in use. The context was already in the editor, not typed, which a keyboard may treat differently. Twenty-nine of the 150 targets also appear as a context word in some other phrase. Twenty-three targets are three letters long. The phrase set has been public since 2003 and could be in either keyboard’s training text. A first run of this probe at exact key centers showed Gboard at 14% and was the run that exposed the key-center problem.

Latency

Both keyboards commit a letter on key release, or when the next finger lands while a contact is still down, so the time from that trigger to the editor change is the part the keyboard controls. In the native field with scattered taps, over 1,131 to 1,620 characters per cell before any correction, from the test editor’s own clock:

At the median the two are within a millisecond on the Pixel 9a, and Gboard is 3 ms sooner on the Pixel 10. LocalType’s 95th percentile is 2 to 5 ms higher. Every figure is under one 16.7 ms frame. This excludes touch-sensor and display latency and is not typing speed. An earlier version of this section used runs at 30 and 120 ms typed at exact key centers and said Gboard was up to 4 ms sooner; those runs had Gboard in its changed state and are no longer quoted. In them, typing at 30 ms with overlapping contacts left LocalType’s output identical to its output at 60 and 120 ms.

Learning

A first probe typed ten pronounceable non-words three times each. Gboard kept every one at every exposure in both fields on both phones, so the probe could not show Gboard learning: there was nothing for it to stop altering. LocalType altered the same three at every exposure (frostune to fortune, plankish to planish, vexamine to examine), kept seven, and never offered a non-word, which is its documented design: an unknown raw spelling is not learned without a deliberate keep.

A second probe measured LocalType 0.5.14’s one-use rule alone: 24 invented dialogues, each typing a four- to six-word context, probing the strip, typing the context with a sentence-final word such as teal or cedar, probing again, and repeating. The Pixel 9a offered the word after one use in 22 of 24 probes and after two in 22 of 24, from 0 of 24 before; the Pixel 10 was at 9 of 10 when its run stopped on an adb transport error, restoration verified. Under the earlier two-use rule, on October 9, LocalType had offered 0 of 24 after the second exposure against Gboard’s 23 of 24; Gboard was not rerun.

What this does not show

• Scripted taps at fixed spacing are not human typing. Nothing here is words per minute, composition, or a practised user; a transcription mode exists for that question and has had only a scripted smoke test. Whether LocalType’s edge at accurate taps survives real fingers, where Gboard’s decoder is built to work, is the open question.
• Gboard reacted to one unnatural property of scripted taps, the absence of any scatter, by changing its behaviour. It may react to others I have not found, such as the fixed 60 ms rhythm. The scattered-tap rows show no sign of it, but that is the absence of a symptom, not a proof.
• The tap-spread model is a choice: Gaussian, the same in both axes, held inside the key area. Three spreads are published; a different model could change the automated winner at the wider spreads.
• The prediction probe reads strips; it does not measure words accepted, and its limits are listed with it.
• Gboard’s model identity, language packs and settings beyond its own reset are not observable; both keyboards were measured after their supported reset, not from a factory state.
• Two phones agreeing says the harness is deterministic, not that two phones are two samples.
• The learning section is from October 10 and was typed at exact key centers, so its finding that Gboard kept every non-word cannot be read as Gboard’s behaviour.
• The author of the benchmark is the author of one of the keyboards.

Corrections

October 11, 2026, a fourth time, from an independent review of this page. I had written that 19% of Gboard’s letter taps at 33 px landed off their key against 12% of LocalType’s, because Gboard’s keys leave gaps. That was wrong: Gboard reports both a key’s cell and the smaller label inside it, and my scorer measured against the label. Against its cells the figure is 11%, and Gboard’s rows are the taller ones. Correcting it moved some of Gboard’s outcomes under spread from wrong to unchanged (24 to 21 at 23.5 px, 49 to 38 at 33 px); no corrected count changed. The latency section now uses scattered-tap runs only. The page also now says that two Pixel 10 cells took a second block, and that it is the counts, not the texts, that agree within two words between phones.

October 11, 2026, a third time, and the most important. The key-center rows are withdrawn: the comparison this page led with, 133 against 2 in the native field, measured a reaction of Gboard’s to perfectly centered taps and not its ability to correct. The explanation is under the tables. The card, the write-up, the model card and the LocalType download page carried that figure for some hours on October 10 and 11 and have been corrected.

Earlier on October 11, twice. The first version of this page showed Gboard’s corrected counts under spread as 103, 105 and 103 at 14, 23 and 33 px. Those figures left out the typos Gboard both corrected and capitalised; the right figures for those runs were 110, 112 and 111. The paired differences were computed from the right figures. The same day I fixed how the scorer attributes a tap that lands between or beyond a keyboard’s reported keys, which had charged both keyboards for slips they left alone, and rescored every run from its archived transcripts.

Later that day the spread rows were replaced altogether. The October 10 spread was first defined on each keyboard’s own reported key width, which gave LocalType more pixels of noise than Gboard, so it favoured Gboard, not LocalType as the method section first said. The equal-pixel rows that corrected for it paired a LocalType rerun with Gboard rows from earlier runs, and the 33 px and web cells had stopped part-way when a stray tap left the keyboard. The table above is from a single frozen run of both keyboards at pitch-defined spreads in which every cell completed. For the record, the stitched October 10 figures after rescoring were LocalType 134, 127 and 101 of 174 against Gboard 110, 112 and 111 of 200 at 14, 23 and 33 px, with differences of +0.12, +0.075 and +0.03; the new run’s are +0.155, +0.105 and +0.05. The key-center rows were 133 against 4 and 91; they are now 133 against 2 and 89. Three other phrases were put right: the key pitch is about 107 px, Gboard is up to 4 ms sooner at the median rather than 1 to 4, and LocalType’s 95th percentile is 2 to 7 ms higher rather than 4 to 7.

Builds: LocalType 0.5.14 (34) and Gboard 18.4.1.985164140-beta-arm64-v8a. The harness, cases, scorer and the pinned sources of every run live in the LocalType repository (verification/editor-fixture); the run directories with every transcript and restoration receipt are kept offline.

Chime write-up · Methods and measurements · Download LocalType