Analyze your code's time and space complexity. Paste Python, JavaScript, Java, C++, C# or Go and see the loop-by-loop derivation behind the Big-O.
Paste a complete function for the best reading. Comments and strings are ignored, so a loop written inside a string will not be counted.
Optional. Time a simple loop on the machine that will run this and divide its iterations by the seconds it took — we publish no figure for how fast a computer is. Leave it blank and the analysis is unchanged.
The eight classes almost every algorithm falls into.
| Notation | Name | Growth | Practical limit |
|---|---|---|---|
| O(1) | Constant | No growth | Unbounded |
| O(log n) | Logarithmic | +1 step per doubling of n | Billions |
| O(n) | Linear | 2x input, 2x time | Tens of millions |
| O(n log n) | Linearithmic | A little steeper than linear | Millions |
| O(n²) | Quadratic | 2x input, 4x time | Tens of thousands |
| O(n³) | Cubic | 2x input, 8x time | Hundreds |
| O(2^n) | Exponential | +1 element, 2x time | About 30–40 |
| O(n!) | Factorial | +1 element, (n+1)x time | About 10–12 |
Average-case cost per operation, with the space the structure itself occupies.
| Structure | Access | Search | Insert | Delete | Space |
|---|---|---|---|---|---|
| Array | O(1) | O(n) | O(n) | O(n) | O(n) |
| Linked list | O(n) | O(n) | O(1) | O(1) | O(n) |
| Stack | O(n) | O(n) | O(1) | O(1) | O(n) |
| Queue | O(n) | O(n) | O(1) | O(1) | O(n) |
| Hash table | N/A | O(1) | O(1) | O(1) | O(n) |
| Binary search tree | O(log n) | O(log n) | O(log n) | O(log n) | O(n) |
| AVL tree | O(log n) | O(log n) | O(log n) | O(log n) | O(n) |
| Red-black tree | O(log n) | O(log n) | O(log n) | O(log n) | O(n) |
| B-tree | O(log n) | O(log n) | O(log n) | O(log n) | O(n) |
| Heap | N/A | O(n) | O(1) | O(log n) | O(n) |
Best, average and worst-case time, the extra space required, and whether equal elements keep their original order.
| Algorithm | Best | Average | Worst | Space | Stable |
|---|---|---|---|---|---|
| Quicksort | O(n log n) | O(n log n) | O(n²) | O(log n) | No |
| Merge sort | O(n log n) | O(n log n) | O(n log n) | O(n) | Yes |
| Heapsort | O(n log n) | O(n log n) | O(n log n) | O(1) | No |
| Timsort | O(n) | O(n log n) | O(n log n) | O(n) | Yes |
| Bubble sort | O(n) | O(n²) | O(n²) | O(1) | Yes |
| Insertion sort | O(n) | O(n²) | O(n²) | O(1) | Yes |
| Selection sort | O(n²) | O(n²) | O(n²) | O(1) | No |
| Radix sort | O(nk) | O(nk) | O(nk) | O(n + k) | Yes |
| Counting sort | O(n + k) | O(n + k) | O(n + k) | O(k) | Yes |
| Bucket sort | O(n + k) | O(n + k) | O(n²) | O(n) | Yes |
This analyzer reads code structure — loop nesting, loop step form, recursion shape, known library costs and allocations. It cannot see data-dependent behaviour, library internals, or logic that changes the trip count at runtime. Treat the result as a well-evidenced reading of the code you pasted, and check the derivation against your own understanding.
You might also find these calculators useful
Paste your code and get its cyclomatic complexity, function by function
Array memory footprint, and how to read its length
Coverage by criterion, checked against requirements we can cite
Count SLOC, comments and blanks from pasted code, then estimate effort
Paste a function and this calculator reads its structure — how loops nest, how each loop advances, how a recursive call shrinks its argument, which library calls hide a scan — and reports both the time and the space complexity. Every conclusion is listed against the line that produced it, so you can check the reasoning rather than take a notation on trust. Nothing is uploaded: the analysis runs entirely in your browser.
Big-O describes how the work an algorithm does grows as its input grows, ignoring constant factors and lower-order terms. An O(n²) function is not necessarily slow — on ten elements it may well beat an O(n log n) one — but as n rises the growth rate decides the outcome, and no amount of micro-optimisation changes the class. Time complexity counts basic operations; space complexity counts memory. Both are reported here, because a solution that trades one for the other is only judged fairly when you can see both.
The definition
Write a solution, check the complexity you think it has against the one its structure actually implies, and see exactly which line makes it quadratic when the two disagree.
A function that scans a list inside a loop passes tests and fails in production. Pasting the diff's hot function gives a reviewable, line-referenced reason to ask for a set instead.
The derivation makes the abstract rules concrete: sequential blocks take the maximum, nested blocks multiply, and a halving step contributes a logarithm.
Analyze both and compare the notations and the operation counts at the input size you actually expect, rather than at the asymptote.
Most online Big-O tools send your snippet to a language model and return a bare O(...) with no reasoning. When it is wrong — and on unusual code it will be — nothing on the page tells you so. Here each finding names the line it came from and what it multiplied the answer by.
A slice inside a loop, a repeated string concatenation, a membership test against a list rather than a set: each looks like one statement and each is a full scan. These are the most common causes of a function that is quietly quadratic, and they are listed explicitly.
Nested loops over two different collections are O(n × m), not O(n²). When the code has two dimensions the analysis names them separately and tells you which variable each one stands for.
Data-dependent loops, pivot-based recursion and unfamiliar library calls are stated as limits rather than papered over with a confident guess.
Count how many times each statement runs as a function of the input size. Sequential blocks take the maximum of their costs; nested blocks multiply. A loop that adds a fixed amount to its counter is linear; one that multiplies or divides it is logarithmic. A recursive function is solved by its recurrence: two calls on half the input plus linear work gives n log n, two calls on n − 1 gives 2^n. This calculator applies exactly those rules and shows each application against a line number.
Python, JavaScript and TypeScript, Java, C and C++, C# and Go. Detection is automatic, and you can override it. The analysis is structural rather than a full parse, so it also copes with an incomplete snippet — a loop body pasted without its enclosing function still reads correctly.
For the loop, recursion and library shapes it recognises, yes — and it shows its working so you can confirm. What it cannot see is behaviour that depends on the data: a loop that usually exits early, a hash table that degrades to a list on adversarial keys, a library call whose cost depends on an argument. Those are reported as limits, not folded silently into the answer.
Time complexity counts operations as the input grows; space complexity counts memory. They frequently trade against each other — memoising a recursive function turns exponential time into linear time by spending linear space. Reading only one of them hides the price of the other, which is why both are shown here.
Auxiliary space is the memory an algorithm allocates on top of the input it was handed. An in-place sort is O(1) auxiliary even though the array it sorts is n elements long, because it did not allocate that array. This is the convention used in interviews and in most textbooks.
Because the two loops iterate different collections. Their sizes are independent, so the cost is the product of two separate dimensions and collapsing it to n² would assert a relationship the code does not contain. The badges under the result show which variable each symbol stands for.
No. The analysis runs in your browser. Nothing is sent to a server, which is also why there is no wait for a response and no rate limit.