Why Speedtype Treats A and a as Different Keystrokes

The short answer

Speedtype compares typed characters with the passage characters in their original case. An uppercase E is not accepted as a lowercase e, even though both letters have the same spoken name. The same exact comparison applies to punctuation and spaces.

That decision is deliberate. A typing result should show whether the text on screen was reproduced, not whether the input would sound similar when read aloud. If a passage contains Enhance and the input is enhance, the first character is unresolved until it is corrected. The displayed character should be marked as an error, and the error count should increase.

This page documents the current product behavior. It does not claim that every typing site must use the same rule.

A worked case-mismatch example

One automated scorer case uses the target word enhance and the typed word enhancE. The word contains seven attempted characters. Six positions match, while the last character differs only by case.

For a 60-second result, Speedtype calculates:

Field	Value	Reason
Attempted keystrokes	7	Seven characters were entered
Unresolved errors	1	E does not equal e
Correct attempted characters	6	Seven attempts minus one unresolved error
Gross WPM	1.4	7 / 5 / 1 minute
Net WPM	1.2	6 / 5 / 1 minute
Accuracy	86%	6 / 7, rounded to a whole percent

This tiny sample is useful for testing the rule, not for judging typing ability. A normal result should use a longer passage and a consistent duration. The complete formulas are documented in the scoring methodology.

What is compared exactly

Speedtype processes text as characters rather than converting both sides to lowercase. That means all of these pairs are different:

Passage	Input	Result
A	a	mismatch
speedtype	Speedtype	mismatch at the first character
.	,	mismatch
straight apostrophe	no apostrophe	mismatch
one space	two spaces	extra input must be corrected

The scorer does perform a small normalization step before comparison. It normalizes Unicode text to NFKC, converts a non-breaking space to a regular space, and converts common curly quotation marks to straight quotation marks. This prevents a visually equivalent quote copied from a rich-text source from becoming an artificial error.

Normalization is not case folding. It does not turn uppercase letters into lowercase letters, remove punctuation, or silently collapse arbitrary whitespace.

Completed words and the current word

There are two related stages in the practice workflow.

A completed word is committed after its following space. Speedtype compares that completed input with the corresponding target word. If the word differs, the error total reflects the number of edits needed to transform one word into the other. This word-level comparison prevents a missing character in one word from making every later character appear wrong.

The word currently being typed is handled differently. Speedtype compares each entered character at its current position. It does not count the untyped suffix as an error, because the word is still in progress. A case mismatch that has already been typed does count.

This distinction is why a test can show one red character now without treating every not-yet-entered character as missing.

What happens after a correction

If you type the wrong case and press Backspace before completing the word, the visible unresolved mismatch can disappear after you enter the correct character. The attempted keystroke still occurred, however. Speedtype keeps an attempt count so the gross result represents typing activity rather than only the final text left in the input field.

That choice matters when reading the result:

• Gross WPM uses attempted keystrokes.
• Net WPM subtracts unresolved errors from attempted keystrokes.
• Accuracy divides correct attempted characters by attempted keystrokes.
• The displayed Errors field describes unresolved errors in the resulting text.

A corrected mistake can therefore increase the work performed without remaining in the final error count. Read what corrections change for a fuller explanation of that tradeoff.

Reproduce the behavior yourself

Use this small protocol so the observation is not dependent on a screenshot:

1. Open Practice.
2. Keep the language, difficulty, and duration unchanged.
3. Find an uppercase character in the passage, usually at the start of a sentence.
4. Enter the lowercase version deliberately.
5. Confirm that the target character is marked as incorrect and the Errors value changes.
6. Press Backspace and enter the correct uppercase character.
7. Confirm that the unresolved marking clears.
8. Reset before using the run as a personal benchmark.

For a second check, reverse the experiment on a lowercase letter by entering its uppercase form. The behavior should be the same.

Why this rule is useful

Case-sensitive grading keeps the task observable. The displayed passage is the specification, and the result reports how closely the entered text matched it. This is especially relevant for names, sentence starts, abbreviations, and code-like text where capitalization can carry meaning.

It also makes automated regression tests straightforward. A test can provide an exact passage, exact input, duration, and expected result. If a future code change accidentally makes comparison case-insensitive, that test fails before release.

The rule does not prove that capitalization practice is the most important goal for every user. Someone focused on motor recovery, assistive input, or a new keyboard layout may reasonably use different success criteria. Speedtype reports the exact-text result; the user decides how to use it.

Known boundaries

The scorer measures text output, not finger technique. It cannot tell whether Shift was pressed with the opposite hand, Caps Lock was used, speech input produced the letter, or an input method composed it. It also does not diagnose why a mismatch occurred.

Browser and operating-system input methods can affect composition before text reaches the app. This is particularly important for Marathi. For fair comparisons, keep the same device, layout, input method, language, and duration. The English and Marathi comparison guide explains why results from different scripts should be tracked separately.

If the app ever marks a wrong-case character as correct, record the target fragment, typed fragment, language, browser, and whether an input method was active. Send that reproducible case through Feedback and Support. A concrete example is more useful than a general report that capitalization is broken.