How to Step through JavaScript Code

What is stepping in JavaScript?

And more to the point… why do I need to read a whole blog post on it?

Two good questions. Well when we’re debugging, stepping removes the guesswork by letting us watch the logic unfold step-by-step. We can pause the code, go through the execution one instruction at a time and isolate the exact point where the bad stuff happens.

This is one of the most reliable ways to understand why a bug happens, not just where it shows up. It also shines a microscope on our code flow, showing us

• Which line runs next.
• Which functions are entered or skipped.
• How values change at each step.

Powerful stuff, right? Well, in this blog we’ll explore the specific use cases in more detail, delve into the various controls at our disposal and build a strategy to use stepping effectively. Here are the full contents, so you can jump to a particular section if you prefer.

When stepping is the right tool

Stepping isn’t the only weapon at our disposal when debugging. We can also set breakpoints, monitor expressions, deploy console.log and call on loads of other tricks and techniques.

Each has its pros, cons and specific use cases. But stepping really comes into its own when:

• A value becomes wrong somewhere in the logic.
• A function is called unexpectedly.
• Control flow depends on conditions or branching.
• The bug doesn’t throw an error, but produces the wrong result.

In short: if you already know where execution pauses (via a breakpoint or debugger), stepping helps answer what happens next.

Breakpoints vs stepping

Just quickly before we move on: best to make double-sure that you grasp the difference between breakpoints and stepping, as many people get them mixed up.

The distinction is actually pretty simple:

• Breakpoints decide where execution stops.
• Stepping decides how execution moves next.

They solve different problems and work best together.

If you want a full guide on breakpoint types and setup, see How to set and manage JavaScript breakpoints.

The stepping controls in Chrome DevTools

Now we’ve done the why, let’s jump to the how.

When execution is paused, Chrome DevTools exposes five stepping controls in the debugger toolbar. Each one answers a slightly different question, all of which piece together to give us a panoramic picture.

• Step (F9): What is the very next piece of code that will execute?
• Step Over (F10): What happens after this line finishes executing?
• Step Into (F11): Where does execution go after this line finishes, without entering any functions it calls?
• Step Out (Shift + F11): When this function finishes, where does execution return to?
• Resume / continue (F8): What happens when I let the program run normally from here?

Now let’s go through them one-by-one.

Step (F9): execute the next line

Step runs the next line of JavaScript. If the next line contains a function call, the debugger enters the function and pauses on its first line.

Be sure to use this when:

• You want full visibility.
• You don’t yet trust any part of the code.
• You need to see every operation.

Step over (F10): run the function, don’t enter it

step over executes the next line without entering function calls. The function runs completely, and execution pauses on the following line.

Use this when:

• You trust the function.
• The function is noisy or irrelevant.
• You want to stay at the current level of logic.

In the example below, we are stepping over the logger() function.

Step into (F11): follow the function call

step into forces the debugger to enter the next function call.

This is useful when:

• A function returns an unexpected value.
• A side effect happens inside the function.
• You suspect the bug lives deeper than the current line.

In the example below, we are stepping into the function logger().

Step over vs step into

This can be a source of confusion if you’re still getting used to the topic, but no dramas: the differences are pretty easy to grasp. Let’s quickly get into that.

The difference lies in the level of detail each feature provides, and the depth of scrutiny we need. Step over gives us a top-line overview, and we use it when we already trust the line. Step into drills into the function; we use it when we don’t trust the line and want a closer inspection.

Step over (F10)	Step into (F11)
Executes the line and skips inside function calls	Enters the called function and pauses at its first line
Treats functions as a black box	Lets you inspect the function line by line
Use when the function is trusted	Use when the function may contain the bug
Faster, keeps debugging focused	Slower, but more precise
Easy to miss bugs inside functions	Easy to waste time in working code

We’d typically use step over when we only care about the result, not the internals. We’d use Step into when we think a bug might be inside the function, we want to inspect parameter values or we’re unsure how the function behaves.

Quick takeaway:

• Bug might be inside the function → Step into
• Bug is outside the function → Step over

Step out (Shift + F11): exit the current function

Step out runs the rest of the current function and pauses execution after it returns.

Use this when:

• You’ve seen enough inside the function.
• The bug isn’t here.
• You want to return to the caller quickly.

In the example below, we are stepping inside the logger() function and then stepping out of it immediately.

Resume / continue (F8): jump to the next breakpoint

Resume continues execution normally until:

• Another breakpoint is hit.
• An exception occurs.
• Execution finishes.

This is not stepping — it’s a controlled “let it run” scenario.

Use it when:

• You’re done inspecting the current section.
• You want to move to the next interesting pause point.

And now, a practical stepping strategy

That’s the five key stepping tools done. Now, let’s get into how and when to use them.

As developers, it’s all too easy to over-use stepping. In other words, to step too much or too early. To avoid falling into this trap, we’d recommend the following:

1. Pause execution at a meaningful point.
2. Inspect values and scope first.
3. Step only when something looks wrong.
4. Step out quickly if the path is irrelevant.

Stepping works best when it’s intentional, not mechanical. And remember to switch regularly between step over and step into, using the distinction we’ve outlined above.

Final thoughts

Stepping through JavaScript turns debugging from guesswork into observation.

Once you’re comfortable switching between step, step over, and step into, many bugs reveal themselves without adding logs or rewriting code.

The key is simple:

Pause intentionally. Step deliberately. Observe before changing anything.