Memory growth observed in CodePen Live Preview after repeated pen edits

Short answer

No, you should not assume the reused Live Preview iframe releases everything after each edit-save cycle. CodePen reuses the same iframe element for performance and resets its contents between previews, but resetting an iframe's document is not the same as guaranteeing that every timer, MutationObserver, cached object, or listener attached during the previous run has been collected. If your pen (or a library it loads) leaves global state behind, memory can grow across repeated saves, and a periodic full page reload is a reasonable mitigation rather than a superstition.

What's confirmed vs. likely

Confirmed by general browser behavior: replacing an iframe's document (via a new src or content rewrite) destroys that document's DOM, but garbage collection only reclaims objects with no remaining references. Listeners or timers that the parent page holds, or callbacks still referenced by the browser's timer queue, can keep the old context alive longer than expected.

Likely, but not officially documented: CodePen's exact teardown sequence is not publicly specified. The documentation describes iframe reuse for speed but does not state when internal resources are cleared. So treat any claim that "the preview is a clean slate after every save" as unverified.

Common leak sources in pens

• setInterval/setTimeout callbacks that are never cleared
• Event listeners attached to window or document without matching removeEventListener
• Third-party libraries that install global hooks, caches, or observers
• Large objects retained through closures in animation loops

Is there a threshold of edits?

No published threshold exists. In practice, growth becomes noticeable after dozens to hundreds of rapid edit-save cycles, and the number depends almost entirely on how much global state each run leaves behind. A pen that only re-renders static markup may show no measurable growth; a pen starting a new setInterval on every save will grow quickly.

How to verify it yourself

1. Open Chrome DevTools on the CodePen editor page and take a heap snapshot (Memory panel).
2. Perform 20–30 rapid edit-save cycles in the pen.
3. Force garbage collection (the trash-can icon in the Memory panel), then take a second snapshot.
4. Compare the snapshots and look for retained objects tied to the preview's contentWindow — detached DOM trees, repeated timer callbacks, or duplicated library instances.

Be careful to isolate the iframe's context: the parent editor page allocates memory of its own, which can mask or mimic a preview leak. Recording a Performance timeline and filtering for timer and listener activity helps separate the two.

Can you depend on iframe reuse alone?

For typical editing sessions, yes — the growth is usually small and irrelevant. For long sessions with heavy pens, no: if you observe steady memory rise, do a manual full page reload, and where possible make the pen clean up after itself (clear intervals, remove listeners, cancel animation frames). That defensive cleanup is good practice regardless of how the host handles teardown.

One caveat worth flagging: CodePen's internals can change at any time, so treat this as behavior to re-verify with the snapshot method above rather than a fixed guarantee.