Clear timeouts in JavaScript: clearTimeout and patterns that scale

Timers let you defer work with setTimeout; clearTimeout cancels that work before it runs if you still have the timer handle. The same names work in modern browsers and in Node.js (the runtime people often mean when they search for cleartimeout nodejs). What does not exist is a built-in “cancel every timeout everywhere” switch—your own code must track the ids it creates and clear them in a batch when you tear down a component, route, or test.

The sections below show single-timer cancellation, clearing many tracked timers, optional chaining for nullable handles, and why brute-force loops over numeric ids are a bad trade. After each runnable block, a short summary explains what you should see in the console (aligned with Node.js timers).

Tested on: Node.js v20.18.2. Descriptions below match the intended console behavior; exact timing of setTimeout(..., 0) may vary slightly by machine load.

Quick reference

Use this table for javascript clear all timeouts and cleartimeout javascript cleanup.

1. setTimeout returns a handle you must keep

setTimeout schedules the callback and returns an opaque handle (in browsers often a number; in Node it may still log like a number in many versions). Keep that handle if you plan to cancel.

const timeoutID = setTimeout(
  (user) => {
    console.log(`${user}, please provide your ID.`);
  },
  0,
  "Jacob",
);

After the timer fires you should see Jacob, please provide your ID. (the example uses delay 0 so it runs promptly in scripts).

The first argument is the callback, the second is the delay in milliseconds (here 0 so the example runs immediately in tests), and further arguments are passed through to the callback—see MDN setTimeout.

2. clearTimeout — clear timeout JavaScript for one id

The standard spelling is clearTimeout (people often type cleartimeout javascript or cleartimeout js). It takes the same handle returned by setTimeout.

If you clear before the callback runs, the callback does not run:

const timeoutID = setTimeout(
  (user) => {
    console.log(`${user}, please provide your ID.`);
  },
  0,
  "Jacob",
);

clearTimeout(timeoutID);
console.log("(timeout was cleared before it could run)");

You should see only (timeout was cleared before it could run)—the Jacob callback never runs because clearTimeout ran first.

If you never assign the return value of setTimeout to a variable, you cannot cancel that timer later—there is nothing to pass to clearTimeout.

3. JavaScript clear all timeouts — track ids, then clear each

For clear all timeouts javascript / js clear all timeouts, keep handles in a Set or array. When you need a full reset, iterate and call clearTimeout on each:

const handles = new Set();
const id1 = setTimeout(() => console.log("one"), 80);
handles.add(id1);
const id2 = setTimeout(() => console.log("two"), 80);
handles.add(id2);

for (const h of handles) {
  clearTimeout(h);
}
handles.clear();
console.log("cleared:", handles.size);
setTimeout(() => console.log("tick"), 120);

Expect cleared: 0 first, then tick after the later timer fires. Neither one nor two appears because both handles were cleared before 80 ms. A tick line still arrives from a new timer scheduled after the mass-cancel—showing that javascript clear all timeouts only applies to the ids you tracked.

Alternative using an array:

const ids = [];
ids.push(setTimeout(() => console.log("first"), 100));
ids.push(setTimeout(() => console.log("second"), 100));
while (ids.length) {
  clearTimeout(ids.pop());
}
console.log("all pending timeouts cleared");
setTimeout(() => console.log("done"), 150);

You should see all pending timeouts cleared before done; the first / second callbacks never fire because their ids were popped and cleared.

4. Optional chaining order (teardown)

If the value might be undefined, compute the handle first, then clear—mirrors the “safe order” pattern used elsewhere when cancelling work:

let timeoutID;
timeoutID = setTimeout(() => console.log("nope"), 50);
clearTimeout(timeoutID);
console.log("step 1");
console.log("step 2");
setTimeout(() => console.log("step 3"), 100);

You should see step 1, then step 2, then step 3 on separate lines, with no nope output—the 50 ms timer was cleared before it fired. The step 3 line comes from a separate timer used only to keep the event loop alive long enough to observe behavior in a short script.

5. Why not for (let i = 0; i < 10000; i++) clearTimeout(i)?

Some older articles suggest brute-forcing numeric ids. That can cancel timers you do not own, fight third-party code, and behave differently across engines. On Node.js, handles are not guaranteed to be small integers you should scan. Prefer the registry pattern in section 3—this is what most javascript cancel timeout / cleanup answers on Stack Overflow converge on for maintainable apps.

6. Related ideas

• clearInterval — for repeating timers; users mixing js clear all timeouts with intervals should cancel setInterval with clearInterval using the interval’s handle.
• AbortController — for cancelling network or async work; related to “cancel” wording but not a substitute for clearTimeout on a timer handle.

Summary

• Keep every setTimeout handle you need to cancel; clearTimeout is a no-op for bad ids but cannot guess your timers.
• Track ids in a Set or array and clear in bulk when unmounting or resetting.
• Never scan arbitrary numeric ranges to clear unrelated timers.

References

MDN and Node references for setTimeout, clearTimeout, and registry-style cleanup.

• MDN: clearTimeout()
• MDN: setTimeout()
• Node.js: Timers
• Stack Overflow: How to clear all JavaScript timeouts?