Big O Calculator for JavaScript: Time and Space Complexity

A Big O calculator for JavaScript is only useful if it shows its work. I built Complexity Coach, a free tool that reads your code and estimates its time and space complexity, because most answers I found online were either a bare "O(n)" with no reason or a confident guess.

In this guide I explain how Big O notation maps to real JavaScript, which built-in methods hide extra cost, how time and space complexity differ, and where a static calculator, including mine, should refuse to guess.

Big O notation in plain words

Big O describes how the work grows when the input grows. It ignores the exact number of milliseconds, because that depends on the machine. It only asks: if the input doubles, what happens to the work?

• O(1): the work stays the same, like reading arr[5].
• O(log n): the work grows very slowly, like binary search, which halves the range each step.
• O(n): the work grows with the input, like one loop over an array.
• O(n log n): typical for good sorting.
• O(n²): every item compared with every other item, usually two nested loops.

Two rules do most of the work. Drop constants, so O(2n) is just O(n). Keep the biggest term, so O(n² + n) becomes O(n²). The second rule has a catch I will come back to, because it only applies when the terms use the same input.

How to read Big O from JavaScript code

You do not need maths to estimate Big O for most interview or product code. You need to count how many times each line can run.

Loops multiply, separate blocks add

One loop over n items is O(n). A loop inside another loop multiplies: O(n × n), or O(n²). Two loops one after the other add: O(n + n), which is still O(n).

function hasDuplicate(nums) {
  for (let i = 0; i < nums.length; i++) {        // n times
    for (let j = i + 1; j < nums.length; j++) {  // up to n times each
      if (nums[i] === nums[j]) return true;
    }
  }
  return false;
}
// Time: O(n²)  Extra space: O(1)

Different inputs get different letters

This is the most common mistake I see. If the outer loop runs over comments and the inner loop runs over bannedWords, the answer is O(m × n), not O(n²). Writing n² hides the fact that a long banned-word list hurts just as much as a long comment list.

The same applies to adding terms. O(m × L + n) cannot be simplified to O(m × L), because n is a different input. "Keep the biggest term" only works when the bigger term contains all the same sizes.

Halving means logarithmic

When each step cuts the remaining range in half, like binary search with a mid index, the loop runs about log₂ n times. For a million items, that is around 20 steps.

Recursion needs a recurrence, not a glance

Recursive code is where quick estimates go wrong. Count how many calls each call makes and how deep the calls go. The naive Fibonacci function below calls itself twice per step, so the number of calls roughly doubles at each level:

function fib(n) {
  if (n < 2) return n;
  return fib(n - 1) + fib(n - 2); // two calls per call: about O(2^n)
}

function fibMemo(n, memo = new Map()) {
  if (n < 2) return n;
  if (memo.has(n)) return memo.get(n);
  const value = fibMemo(n - 1, memo) + fibMemo(n - 2, memo);
  memo.set(n, value); // each n is computed once: O(n) time, O(n) space
  return value;
}

The memoised version does the same maths but stores each answer, so every value of n is computed once. The call stack still grows to depth n, which is why its space is O(n), not O(1).

Hidden costs in JavaScript array and string methods

Many JavaScript methods look like one cheap line but contain a loop. A single includes inside a loop is often what turns O(n) code into O(n²).

Two of these deserve a source. V8, the engine in Chrome and Node.js, has used TimSort for Array.prototype.sort since version 7.0, which gives O(n log n) in the worst case. For Map and Set, the ECMAScript specification only requires access times that are sublinear on average. Engines use hash tables, so O(1) on average is the honest way to say it.

The fix for a hidden scan is usually a Set:

// Slow: includes scans bannedWords for every word, O(w × b)
const isClean = words.every((word) => !bannedWords.includes(word));

// Fast: build the Set once in O(b), then each lookup is O(1) on average
const banned = new Set(bannedWords);
const isCleanFast = words.every((word) => !banned.has(word));

Two more patterns catch people in code reviews. The first is a queue built on shift(). In a breadth-first search, calling queue.shift() on every step usually moves all remaining items forward, so a loop that looks linear can become O(n²) on large inputs. Keeping a head index and reading queue[head++] avoids the move.

The second is copying inside a loop. Writing acc = [...acc, item] inside reduce copies the whole array on every step, which is also O(n²) time and creates a lot of short-lived garbage. Pushing into one array keeps it at O(n). Neither pattern is wrong for small lists, but both are worth a comment when the list comes from users.

Strings need their own letter. comment.split(" ") reads the whole comment, so its cost depends on the comment's length, not on how many comments there are. I use L for that.

Time and space complexity, including the output

Time complexity counts steps. Space complexity counts extra memory. Interview answers usually separate two kinds of space:

• Auxiliary space: memory your algorithm needs while working, such as a Set of seen values or a temporary copy.
• Space including output: auxiliary space plus the array you return.

A function that fills and returns a result array of n items has O(n) total space, but its auxiliary space can still be O(1):

function doubled(nums) {
  const result = new Array(nums.length); // the output: counts only in total space
  for (let i = 0; i < nums.length; i++) {
    result[i] = nums[i] * 2;             // one index variable: O(1) extra
  }
  return result;
}
// Time: O(n)  Auxiliary space: O(1)  Space including output: O(n)

Mixing these two up is why two people can look at the same code and give different answers that are both partly right. Complexity Coach shows both values side by side for this reason.

How I built Complexity Coach, and where it refuses to guess

Complexity Coach runs in your browser. It parses the code into an abstract syntax tree (AST) with the Acorn parser, so nothing is sent to a server. It then walks the tree, tracks how loops nest, recognises known array, Map, Set and string operations, highlights the lines that drive the result, and gives a confidence level: High, Medium or Manual review needed.

The rule I care about most is that it does not invent answers. Recursion, calls to helper functions it cannot see, loops without a clear bound and dynamic property access all return "Manual review needed" with the reason and the exact line. A wrong O(1) is worse than no answer, because people trust it.

That rule also showed me a gap. When I tested a comment filter that split each comment into words and checked them against a Set of banned words, the tool answered "Manual review needed", because it did not know split(). Honest, but not useful for very common code. I added the common string methods with L as the string length, and the same code now returns O(m × L + n) time, O(n + L) auxiliary space and O(m + n + L) including the output.

The same test exposed a second problem: an earlier version dropped the n term and answered O(m × L). Building a Set of n banned words is real work that the bigger term does not cover, so smaller terms are now kept whenever they use a different input.

Static analysis or a runtime benchmark?

There are two kinds of Big O calculator. Runtime tools, such as the big-o-calculator package on npm, run your function with growing input sizes and fit the timings to a curve. Static tools, like Complexity Coach, read the code without running it.

Runtime measurement sees real data, but timings are noisy because of JIT warm-up and garbage collection, and the result depends on the test inputs you chose. Static analysis explains why the code grows the way it does, but it cannot know the shape of your production data. I use the static estimate while writing and reviewing code, and a benchmark when a specific function is actually slow.

Practical takeaway

Before you trust any Big O calculator, check five things yourself:

1. Give each input its own letter, so m × n never hides as n².
2. Multiply nested loops and add separate blocks.
3. Look inside one-line methods such as includes, slice, sort and split.
4. Report auxiliary space and space including the output separately.
5. Treat recursion as a manual task: write the recurrence instead of guessing.

If you want a second opinion with the evidence on each line, paste your function into Complexity Coach; it is one of my free developer tools. If you need help with performance in a real Node.js or SaaS codebase, get in touch.