Skip to content
Lizely

Key Press Counter

Count keydown events inside a focused capture area, inspect per-key frequencies and recent labels, and optionally include held-key repeats.

Privacy: your files never leave your device. All processing happens locally in your browser.

How to use

  1. 1.Click the dashed capture area so it has focus, then press neutral test keys; use Tab whenever you want to leave it.
  2. 2.Leave held-key repeat counting off for one count per physical hold, or enable it to include browser events marked repeat.
  3. 3.Review the total, recent ten labels, and sorted frequency table, then select Reset counter to clear the local session.

About Key Press Counter

Key Press Counter counts browser keydown events only while its visible capture area has focus. Click the area, press keys, and watch the total, recent ten labels, and per-key frequency table update. By default, automatic repeat events produced while a key is held are ignored. Enable Count held-key repeat events when those repeated events are part of the activity you want to observe. Reset clears the total, frequency map, and recent history.

The counter is different from a keyboard tester. A keyboard tester usually lights a layout to help locate keys that do or do not generate events. This tool focuses on quantity and distribution: how many accepted keydown events occurred, which browser key label appeared most often, and in what recent order. It does not draw a physical layout, identify a keyboard model, test every switch, calculate words per minute, score accuracy, or decide whether a key is defective.

Focus is an explicit boundary. Keystrokes typed elsewhere on the page or in another application are not counted. The capture area leaves Tab available so keyboard users can move focus out instead of becoming trapped. For other keys, the page prevents the usual default action while the area is focused, reducing accidental scrolling or button activation. Browser and operating-system shortcuts can still be intercepted before a web page receives them, so not every physical action is guaranteed to create a record.

Labels come from the browser KeyboardEvent key value. A literal space is displayed as Space, a single visible character is shown in uppercase where locale conversion supports it, and named values such as ArrowUp remain readable. Control characters, surrogate code points, and Unicode line or paragraph separators are removed. An empty result becomes Unknown, and labels are limited to forty Unicode code points before storage. This protects the on-page table from malformed synthetic events without claiming a universal keyboard map.

Held-key behavior matters when comparing totals. Browsers commonly deliver an initial keydown followed by events marked repeat while a key remains depressed. With the toggle off, those marked repeats return the existing state unchanged. With it on, each received repeat increments the total and that key's frequency. The tool trusts the browser's repeat flag; it does not measure the physical debounce interval or independently determine whether repeated events came from a held key, chatter, automation, or accessibility software.

The frequency table sorts keys by descending count and then by label for stable ties. Recent history retains only the last ten accepted labels, while the frequency map covers the current session. This makes it possible to confirm patterns such as A three times and Space twice without preserving a complete reconstruction of everything typed. Even so, do not enter passwords, private messages, recovery codes, or other sensitive material into any test area. Use neutral test keys instead.

Synthetic events, browser extensions, remote-desktop software, input methods, accessibility tools, and on-screen keyboards can all influence the events a page receives. Composed text may not correspond one-to-one with physical switches. Mobile keyboards may produce different labels or editing behavior. The counter therefore reports browser events, not hardware truth, scan codes, polling rate, latency, layout correctness, or the contents of an input field.

Everything runs in the current browser tab. Accepted labels and counts are not uploaded, saved to an account, copied automatically, or retained after refresh. The widget has no hidden document-wide listener; its handler is attached to the visible focusable area. The reliable contract is limited to product-defined label cleanup, explicit repeat policy, immutable count updates, a ten-label recent view, stable frequency sorting, and a manual reset that returns the session to zero.

Methodology & sources

Accept keydown events only from the focused capture element and leave Tab uncounted for accessible focus exit. Convert literal space to Space, remove control, surrogate, line-separator, and paragraph-separator code points, trim, cap labels at forty Unicode code points, and uppercase single visible characters for display. Ignore events marked repeat unless the user enables repeat counting. For each accepted event, immutably increment the total and normalized-label frequency, and retain the latest ten labels. Sort frequency rows by descending count and locale label for ties. Tests assert label normalization, repeat policy, exact totals, bounded recent history, and deterministic sorting.

Frequently asked questions

Why are held keys sometimes counted only once?
Automatic repeat events are ignored by default. Enable the repeat option when you want every browser keydown event marked repeat to count.
Does the counter capture keys everywhere?
No. Its handler is attached only to the visible capture area while that area has focus. Tab remains available to leave the area.
Can this diagnose keyboard chatter or a broken switch?
No. It reports browser keydown labels and repeat flags, which can be affected by software, input methods, accessibility tools, and operating-system handling.

Related tools

Device & Productivity guides

View all