b2KIT

Memory Leak Detector

Run JavaScript code and track object allocation, detached DOM nodes, and closure references for leaks.

Tested tool guide Tested browser tools Checked August 16, 2026

What Memory Leak Detector does and how it behaves

Memory Leak Detector executes a JavaScript snippet in the browser and watches the run for three kinds of evidence: object allocations, DOM nodes removed from the document but still referenced, and values retained through closures. It is intended for isolating a small reproduction, not for declaring every allocation a leak. The common surprise is that a detached node or captured object can be legitimate. The result identifies retention candidates; whether they are bugs depends on whether the program still needs them after the tested operation. The snippet and inspection results are not uploaded by the tool.

How the result is produced

1

Monitored execution

The tool runs the entered JavaScript as a browser-side test and tracks objects allocated during that execution. For a useful result, the snippet should contain the smallest setup and cleanup sequence that reproduces the suspected retention. Allocation information shows what the run created, but allocation by itself does not establish that an object remained reachable longer than intended.

2

Retention evidence

Detached-node tracking identifies DOM nodes that have been removed from the active document while references to them remain. Closure tracking highlights values kept reachable through a function's captured lexical environment. These two views help distinguish a node-retention problem from ordinary object creation, but the developer must decide whether each surviving reference is expected.

Good uses

  • Test a component teardown that removes its DOM subtree but may leave references to child nodes in event handlers, registries, or surrounding state. A compact create-remove sequence makes detached-node evidence easier to interpret than a full application run with unrelated allocations.
  • Investigate code that repeatedly opens and closes a dialog, panel, tooltip, or temporary widget. Run a reduced version of one lifecycle and inspect whether the removed interface nodes remain referenced after the code performs its intended cleanup.
  • Examine a callback factory, timer handler, or subscription whose closure captures a large object or DOM element. Closure-reference tracking can show that the captured value remains reachable through the returned function even when the surrounding operation appears finished.

Limits and checks

  • Do not treat a high allocation count as a leak. JavaScript programs routinely allocate short-lived objects, and collection may occur later. A leak diagnosis requires evidence that unwanted objects remain reachable across the lifecycle point where the program should have released them.
  • A detached DOM node is not automatically erroneous. Applications sometimes remove nodes temporarily and retain them for reinsertion, caching, or off-document construction. Interpret the finding against the snippet's intended lifecycle and look for a reference that should have been cleared.
  • Closure retention describes reachability, not developer intent. A captured value may be required for a callback that is still usable. Garbage collection timing is also controlled by the browser, so a single short run should not be read as an exact measurement of eventual memory use.

Common questions

Does a reported object prove that my code has a memory leak?

No. The report supplies evidence about allocation or continued reachability during the monitored run. An object is a leak only when the application no longer needs it but some reference still prevents reclamation. Confirm the intended cleanup point, identify the retaining reference, and reproduce the behavior before labeling it a defect.

Why can a removed element still appear as a detached DOM node?

Removing an element from the document changes its document connection; it does not erase JavaScript references to it. A variable, collection, listener-related object, or closure may still make the element reachable. The finding is actionable when that reference outlives the element's intended use, but it can be harmless when reinsertion is planned.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools

JSON Formatter & Validator

Format, validate, and beautify JSON with syntax highlighting and error detection.

Base64 Encoder / Decoder

Encode text or files to Base64 and decode Base64 strings back to their original form.

SQL Formatter & Beautifier

Format and indent SQL queries for better readability across all major dialects.

HTML to Markdown Converter

Convert HTML markup into clean Markdown syntax with support for tables and lists.

Markdown to HTML Live Preview

Write Markdown and see the rendered HTML output in real time with live preview.

Diff / Patch Viewer

Visualize unified diffs and patch files with color-coded additions and deletions.