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. 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 either exactly on the key centers, or with a seeded Gaussian spread. The spread was first defined as a fraction of each keyboard’s own reported key width, which turned out to favour LocalType (its keys report 106 px against Gboard’s 93 px inside the same 108 px pitch), so LocalType was rerun at Gboard’s pixel spreads of 14, 23 and 33 px and those are the rows below; the fixture now defines the spread on the shared key pitch.

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, with name capitalisation and realised to realized reported apart and not counted as damage, and under spread a clean word left exactly as its taps landed counted as unrepaired noise rather than damage. 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.

Correction

At exact key centers Gboard’s automatic correction in this native field barely acts, four of 200, so LocalType’s 133 is a large difference there; in the web text box Gboard corrects 91. With spread Gboard’s spatial decoder comes alive and holds 102 to 105 corrections at every spread, while LocalType corrects more at 14 and 23 px and falls to a tie at 33 px, where it also starts changing clean words (7 of 174) and its character error rate tips above Gboard’s within the interval. Equal pixels is equal noise, not equal difficulty: inside the same pitch LocalType’s wider keys turn 33 px into 11.5% off-key taps against Gboard’s 18.5%. LocalType makes more wrong corrections at key centers (16 against 0 native, 9 web). Neither keyboard dropped or doubled a character in any cell. The web rows under spread are partial because the fixture stopped on its own clipboard-restoration check; the completed sentences are reported with their denominators and nothing was retried silently.

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 native fields, over 738 to 1,619 characters per cell before any correction, from the fixture’s own clock:

Gboard is 1 to 4 ms sooner at the median and LocalType’s p95 is 4 to 7 ms higher, both under one 16.7 ms frame at the median. This excludes touch-sensor and display latency and is not typing speed. Typing at 30 ms with overlapping contacts left LocalType’s output byte-identical to the 60 and 120 ms runs.

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.
• The tap-spread model is a choice. Five spreads are published and the key-center row is the headline; a different model could change the automated winner at the wider spreads.
• Next-word prediction was not measured. The October 8 pilot that counted strip offers was confounded by unequal prior learning, so on prediction there is no controlled result either way.
• 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.
• Both phones gave LocalType byte-identical text and Gboard results within two words, which says the harness is deterministic, not that two phones are two samples.
• The author of the benchmark is the author of one of the keyboards.

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