Match keys by event.code, label them with event.key

event.key is the character the key produces, and it changes with the layout and Shift. Press the same physical key on a French layout and you get a instead of q. Shift+1 gives !. A tester that matches on key can't light the right key cap for half the keyboard.

event.code is the physical position (KeyQ, Digit1, NumpadEnter), and it stays the same whatever language the keyboard is typing in. So light keys by code and show key as the label:

const CODE_ALIASES = { OSLeft: 'MetaLeft', OSRight: 'MetaRight', NumpadComma: 'NumpadDecimal' };
const codeOf = e => CODE_ALIASES[e.code] || e.code;

document.addEventListener('keydown', e => {
  const code = codeOf(e);
  light(code, true);           // the physical key cap
  showLabel(e.key);            // what it typed on this layout
});

The aliases cover older browsers that reported the Windows/Command keys as OSLeft/OSRight.

Stop the browser acting on keys, but keep real shortcuts

Testing F5, Tab, Space or the arrow keys shouldn't reload or scroll the page, so preventDefault() on keydown. But blocking everything traps people: Ctrl+W, Ctrl+T, Ctrl+R and Cmd+L should still work. Let a combination through when Ctrl or Cmd is held with a non-modifier key:

const shortcut = (e.ctrlKey || e.metaKey) && !/^(Control|Meta|OS|Alt|Shift)/.test(code);
if (!shortcut) e.preventDefault();

Keys get stuck in your tester, not in the keyboard

The classic bug is a key that stays lit after you've let go. It's almost never the keyboard. The page simply never received the keyup:

• Alt+Tab, Cmd+Tab, or clicking another window. The keyup goes to whatever has focus by then.
• The Mac command key. While command is held, macOS swallows the keyups of other keys held with it.

So release everything on blur, on visibilitychange, and when command is released:

window.addEventListener('blur', releaseAll);
document.addEventListener('visibilitychange', () => { if (document.hidden) releaseAll(); });
document.addEventListener('keyup', e => {
  const code = codeOf(e);
  held.delete(code);
  if (code === 'MetaLeft' || code === 'MetaRight') releaseAll();
});

Otherwise you're telling someone their keyboard is faulty when it isn't.

Some keys only send keyup

Print Screen on Windows, and some media keys, never produce a keydown the page can see. The OS takes it first. Only the keyup arrives. If you only listen for keydown, those keys look dead. So treat a keyup for a key you never saw go down as a press:

if (!held.has(code)) markTested(code);   // PrintScreen and friends

And some keys send nothing at all

The Mac fn (globe) key and Touch ID never reach a web page. Draw them, but mark them "not testable" and leave them out of the progress count. Otherwise nobody can ever reach 100%, and the honest answer ("the browser can't see this key") gets lost in "your fn key is broken".

Count rollover while you're at it

Holding several keys at once is how you find a keyboard's rollover limit (cheap boards often register only a few simultaneous keys before dropping or ghosting). Track the largest number of keys held at the same time:

held.add(code);
maxHeld = Math.max(maxHeld, held.size);

Press as many keys as you can together. If the count stops rising, that's the limit, at least for that combination of keys, because rollover on cheap keyboards depends on which keys share a matrix line.

Draw the real keyboard

Windows and Mac keyboards differ: Ctrl/Win/Alt/Menu versus control/option/command, a half-height function row on MacBooks, and inverted-T arrows. I describe each layout as a table on a quarter-key grid (half-key rows), so a 2.25-wide Enter, a stacked arrow pair and a two-row numpad Enter are all just grid placements. It's far easier to maintain than hand-written markup.

I built the keyboard tester linked above. Drafted with AI assistance; the details are taken from the production code.

Water and dust are different problems

A low frequency moves a speaker cone a long way on every cycle. That large excursion acts like a tiny pump, nudging droplets sitting in the grille up and out. Around 165 Hz is a sensible compromise: low enough for real cone movement, but high enough that a phone's tiny driver can still produce it at a useful level. Go much lower and a small speaker barely reproduces it at all.

Dust is different. A slow, long stroke does little to a particle clinging to a mesh, while fast vibration does more. So the dust modes sit much higher (a 2 kHz pulse, and a sweep from 400 Hz to 4 kHz), because loose particles of different sizes let go at different frequencies.

So these are separate modes, not one tone with two labels:

None of these is a guarantee, and the page says so. They're presets chosen for plausible physics, not settings tuned per phone model.

One oscillator, ever

The obvious implementation creates an OscillatorNode per pulse. Don't. An oscillator can't be restarted once stopped, and creating one per pulse is how tools end up with overlapping tones that get louder the longer they run.

Instead, one oscillator runs for the whole cycle, and the pulses are shaped by scheduling ramps on a gain node, all on the audio clock:

const SILENCE = 0.0001;  // exponential ramps can't reach 0
const RAMP = 0.02;       // 20 ms click-free edge

let t = ctx.currentTime;
for (let i = 0; i < count; i++) {
  gain.setValueAtTime(SILENCE, t);
  gain.exponentialRampToValueAtTime(peak, t + RAMP);
  gain.setValueAtTime(peak, t + pulse - RAMP);
  gain.exponentialRampToValueAtTime(SILENCE, t + pulse);
  t += pulse + gap;
}

Because everything is scheduled on AudioContext time, a throttled background tab can't knock the rhythm out of sync. The progress ring on screen runs off a 200 ms timer, but the sound doesn't depend on it. I also cap the number of scheduled events (400), so a bad duration value can't queue thousands of ramps.

Never let the gain jump

A gain that jumps from 0 to full makes a click. On a phone somebody already thinks is damaged, that click sounds like a fault, and like one the tool caused. So every pulse edge is ramped, and changing the power setting swells over 250 ms instead of stepping.

Equal loudness: the dust mode would hurt

Ears are far more sensitive around 2–4 kHz than at 165 Hz. If the dust shake played at the same electrical level as the water pulse, switching modes would make people jump, and tempt them to turn the volume down, which is exactly wrong for the low-frequency modes that need level.

The textbook equal-loudness gap is 30–40 dB, but that comes from the quiet end of the curves. At the levels a cleaning pulse plays at, the curves flatten a lot. A phone speaker's own low-frequency roll-off also makes 165 Hz come out much quieter than its electrical level suggests, while 2 kHz sits in the speaker's best range. Together, a taper of about −8 dB (a gain of 0.4) is enough to stop the dust modes being piercing without throwing away the vibration they exist for. The page also tells people to keep the phone away from their ears in dust mode.

At the end of the chain sits a brick-wall limiter (DynamicsCompressorNode: 20:1 ratio, hard knee, 1 ms attack, threshold −2 dBFS), so nothing ever reaches the device clipped:

oscillator → envelope → power → limiter → output → speakers
                                             └→ analyser (visuals)

The analyser taps the final output, so the visuals show exactly what's handed to the speaker.

What the browser can't know

This is the part most "speaker cleaner" pages skip. A web page:

• can't tell whether any water moved. It doesn't open the microphone, and even if it did, it couldn't measure droplets.
• can't tell which device played the sound. The built-in speaker, a Bluetooth headset and wired earbuds all look the same to Web Audio.
• can't play anything until you tap. Browsers hand back a suspended AudioContext without a user gesture, so start() runs from the button and calls ctx.resume() explicitly.

So the tool reports what it played (mode, frequency, duration) and nothing more. The only verdict on the speaker is your own before-and-after comparison: play a song, run a cycle, play the song again.

Nothing is fetched or uploaded either; the tone is generated in the tab. If a "speaker cleaner" asks you to install something, or claims it detected water, it's telling you more than it can know.

I built the speaker cleaner linked above. Drafted with AI assistance; the details are taken from the production code.

/^(a+)+$/

against "aaaaaaaaaaaaaaaaaaaaaaaaaaaa!" takes exponential time. The browser's main thread is busy the whole time, so clicks, scrolling and even the "Stop" button stop responding. There is no way to interrupt a running RegExp.exec() from the same thread.

I ran into this while building the regex tester on A2Z Tools. The fix turned out to be small: run the match in a Web Worker and kill the worker if it takes too long.

1. Put the matcher in a worker built from a Blob

You don't need a separate file. Build the worker source as a string and load it through a Blob URL:

const WORKER_SOURCE = `
self.onmessage = (e) => {
  const { pattern, flags, text } = e.data;
  try {
    const re = new RegExp(pattern, flags.includes('g') ? flags : flags + 'g');
    const matches = [];
    let m, count = 0;
    while ((m = re.exec(text)) !== null && count < 5000) {
      matches.push({ index: m.index, match: m[0], groups: m.slice(1) });
      count++;
      if (m[0].length === 0) re.lastIndex++; // avoid an infinite loop on empty matches
    }
    self.postMessage({ ok: true, matches, truncated: count >= 5000 });
  } catch (err) {
    self.postMessage({ ok: false, error: err.message });
  }
};`;

Two details matter here:

• Empty matches. A pattern such as /a*/g can match an empty string. Without the lastIndex++, exec() returns the same empty match forever.
• A match cap. Even a fast pattern can return millions of matches. Capping at 5,000 keeps the postMessage payload sane.

2. Give it a time budget and terminate on timeout

worker.terminate() is the one thing that can stop a runaway regex, because it kills the worker's thread no matter what it is doing.

const TIME_BUDGET_MS = 1500;

function runRegex(pattern, flags, text) {
  return new Promise((resolve) => {
    const url = URL.createObjectURL(new Blob([WORKER_SOURCE], { type: 'application/javascript' }));
    const worker = new Worker(url);
    let settled = false;

    const finish = (result) => {
      if (settled) return;
      settled = true;
      clearTimeout(timer);
      worker.terminate();
      URL.revokeObjectURL(url);
      resolve(result);
    };

    const timer = setTimeout(
      () => finish({ ok: false, timedOut: true }),
      TIME_BUDGET_MS
    );

    worker.onmessage = (e) => finish(e.data);
    worker.onerror = (e) => finish({ ok: false, error: e.message });
    worker.postMessage({ pattern, flags, text });
  });
}

The settled flag is there because the timeout and the worker's reply can race. Whichever fires first wins, and the other is ignored.

A new worker per run sounds wasteful, but creating one takes a few milliseconds. It also means a terminated worker never leaves bad state behind for the next run.

3. Validate input before you start the worker

Cheap checks up front save a worker round trip and give clearer errors:

if (pattern.length > 500) return error('Pattern is too long');
if (text.length > 200_000) return error('Test text is too long');
if (!/^[gimsuy]*$/.test(flags)) return error('Flags may only contain g, i, m, s, u, y');

4. Be honest about what a timeout means

When the budget runs out, the UI says the pattern may be vulnerable to catastrophic backtracking on this input. A timeout is not proof that a pattern is unsafe, and finishing in time is not proof that it is safe. A different input could still blow up. If you need a real guarantee for server-side code, use a non-backtracking engine such as RE2. Or check for nested quantifiers like (a+)+ and (a|a)*, which are the usual culprits.

Try it

You can paste ^(a+)+$ and a long run of as followed by ! into the regex tester and watch it time out after 1.5 s while the page stays responsive. The same pattern in a plain <script> would hang the tab.

Disclosure: I'm the founder of A2Z Tools, where this tester lives. This post was drafted with AI assistance; the code is taken from the production tool. It first appeared on DEV.