Code Typing Test

About the code typing test

The code typing test measures how fast and accurately you type real source code, not plain English. It serves a snippet in JavaScript, Python, Rust, or SQL and tracks your words per minute, accuracy, and elapsed time as you reproduce it character for character. Code is far harder to type than prose because it is dense with symbols, the words are not in any dictionary, and a single wrong bracket breaks the program, so a separate test gives a much more honest picture of a developer's real keyboard throughput.

Most typing tests use natural-language passages where autocomplete-style muscle memory and common bigrams carry you along. Code removes those crutches. You are constantly reaching for the number row and the symbol cluster: braces, parentheses, semicolons, angle brackets, underscores, and operators. Practising on code trains exactly those reaches and the indentation discipline that editors expect. The test runs entirely in your browser and nothing you type is uploaded.

The ergonomic reason symbols are slow is that most of them require the shift key plus a finger that leaves the home row. Curly braces and the pipe sit under the right pinky, parentheses share the 9 and 0 keys, and the underscore needs a long stretch to the minus key with shift held. In ordinary prose your fingers spend almost all their time on the 26 letters and the space bar; in code roughly a quarter of keystrokes are symbols, digits, or shifted characters. That is why a developer who types 90 WPM on prose may manage only 55 to 65 WPM on real source, and why deliberate symbol drills pay off more than general typing practice.

How it works

Words per minute for code uses the same standardised definition as any typing test: five keystrokes count as one "word", so symbol-heavy code is scored fairly against prose. Accuracy is the share of characters you got right.

gross WPM  = (characters typed / 5) / minutes elapsed
net WPM    = gross WPM - (uncorrected errors / minutes)
accuracy   = correct characters / total characters typed x 100
1 word     = 5 keystrokes (the universal typing-test convention)

• Five-keystroke word: normalises scores so a line full of symbols is not unfairly slow.
• Accuracy penalty: net WPM subtracts mistakes, so racing ahead with typos lowers your score, not raises it.
• Per-language rhythm: JavaScript is brace-heavy, Python leans on indentation, SQL is uppercase keywords, Rust mixes symbols and type annotations.

Worked example

You type a 250-character JavaScript snippet in 50 seconds with 4 uncorrected errors.

1. Convert to words: 250 characters / 5 = 50 words.
2. Time in minutes: 50 seconds = 0.833 minutes.
3. Gross WPM: 50 / 0.833 = 60 WPM.
4. Net WPM: 60 - (4 / 0.833) = 60 - 4.8 = about 55 WPM, with accuracy near 98 percent.

To raise your net score, prioritise accuracy over raw speed: one wrong symbol is a syntax error, and the error penalty usually costs more than the second you saved by rushing. Drill the specific keys that slow you down, typically the bracket pairs and the shifted symbols, until they are blind reaches. Then rotate languages so no single key pattern dominates your muscle memory. Most people see the fastest gains in the first week as the symbol reaches automate, after which progress slows and accuracy becomes the main lever.

Code typing speed reference

Common pitfalls

• Looking down for symbol keys. The biggest code-typing slowdown is glancing at the keyboard for braces and brackets. Drill the symbol reaches until they are blind.
• Sacrificing accuracy for speed. Net WPM penalises errors, and in real code a stray character is a syntax error. Aim for 97 percent or better before pushing speed.
• Ignoring indentation. Python in particular scores indentation as characters; sloppy spaces or tabs count as mistakes here and break code in practice.
• Practising only one language. Each language stresses different keys. If you only ever type JavaScript, SQL's uppercase keywords and Rust's :: and & will still trip you up.
• Comparing to prose WPM. Your plain-text speed is not your code speed. Expect to be noticeably slower on code, and judge progress against code benchmarks only.
• Neglecting the number row. Code is full of digits and the shifted symbols above them. Weak number-row reach is a common hidden bottleneck.

Related tools

Frequently asked questions