How do iterators and the iterable protocol work?

Q: How do iterators and the iterable protocol work?

**Target Audience:** Engineers preparing for JavaScript fundamentals interviews. **Difficulty:** Medium > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . Every protocol claim below was actually run in Node — including the real failure case. ## 1. Why This Even Matters — A Story First An iterator is like a single ticket-taker at one specific turnstile, who can hand you the next item and tell you when there are no more — a real, working mechanism, but only useful if you already have direct access to that one specific ticket-taker. An iterable is like a building with a clearly marked "start here" sign pointing to WHERE that ticket-taker is — `for...of` and spread syntax only know how to follow the sign (`[Symbol.iterator]`); handed the ticket-taker directly with no sign, they genuinely have no idea where to begin. ## 2. The Core Idea 📌 **Interview term:** an iterator has a real `next()` method. An iterable h

The problem

Question presented to candidate: "What's actually the difference between an 'iterator' and an 'iterable' in JavaScript — aren't they the same thing? And if I hand you an object with just a next() method, will for...of work on it directly?"

What a strong answer should cover:

📌 Interview term: the iterator protocol — an object is an iterator if it has a next() method that returns a real { value, done } object each call — verified directly, hand-driving one through 4 calls, including the final { value: undefined, done: true }.
📌 Interview term: the iterable protocol — an object is an iterable if it has a [Symbol.iterator]() method that RETURNS an iterator — a genuinely separate, distinct protocol from being an iterator itself.
📌 Interview term: the real, direct answer to the prompt — verified directly: a raw object with only a next() method (an iterator, but not an iterable) genuinely fails with a real TypeError when used directly with for...of — for...of, spread syntax, and destructuring all specifically look for [Symbol.iterator], not next() alone.
📌 Interview term: built-in iterables — verified directly: arrays and strings genuinely have a real, built-in [Symbol.iterator], while a plain object genuinely does not — this is exactly why for...of works natively on arrays/strings/Maps/Sets but throws on a plain object (covered in more depth in this bank's own for...of vs. for...in question).
A precise answer names that many objects are BOTH iterators and iterables at once — a generator object (covered in this bank's own dedicated generator-function question) genuinely has both a working next() AND its own [Symbol.iterator] that just returns itself, which is exactly why a generator can be driven manually with .next() calls AND used directly with for...of.

Clarifying questions expected:

None — this is a definitional/technical question; directly answering whether a bare iterator alone works with for...of (it does not) is the strong signal.

Code / implementation expected: Yes — a real, manually-implemented iterator AND a separate real iterable wrapping it, verified working differently with for...of, is the clearest, most convincing demonstration.

iterators

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for JavaScript fundamentals interviews. Difficulty: Medium

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. Every protocol claim below was actually run in Node — including the real failure case.

1. Why This Even Matters — A Story First

An iterator is like a single ticket-taker at one specific turnstile, who can hand you the next item and tell you when there are no more — a real, working mechanism, but only useful if you already have direct access to that one specific ticket-taker. An iterable is like a building with a clearly marked "start here" sign pointing to WHERE that ticket-taker is — for...of and spread syntax only know how to follow the sign ([Symbol.iterator]); handed the ticket-taker directly with no sign, they genuinely have no idea where to begin.

2. The

The solution is hidden so you can try first

4 min read · 9 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptReal proof: a bare iterator fails with for...of, but wrapping it as an iterable via Symbol.iterator fixes it