Memory Test
Monitors browser JavaScript heap via performance.memory on Chromium browsers, and optionally allocates typed-array chunks to watch growth toward the tab limit. Not a hardware RAM test — runs locally, nothing uploaded.
performance.memory is not exposed. Live heap stats show —; allocation is tracked by this tool only (safety cap 300 MB).Live heap stats
—
Used heap (MB)
—
Total heap (MB)
—
Heap limit (MB)
0
Allocated by test
—
Used / limit (%)
Stress allocation
performance.memory, stops at 300 MB self-allocated. Close other tabs if you need headroom.Heap growth graph
Green: used heap · Yellow: total heap · Red dashed: browser limit (Chromium). Updates every 500 ms.
How to use
- Open in Chrome or Edge for full heap stats (
performance.memory). Firefox/Safari show allocation-only mode. - Read Live heap stats — they refresh every 500 ms automatically.
- Set Chunk size (MB) and Interval (ms), then click Start allocating to stress the tab heap.
- Watch the Heap growth graph — green used, yellow total, red dashed limit.
- Click Stop anytime, or let the tool auto-abort at 85% of limit / 500 chunks / 300 MB (no API).
- Click Release & GC to drop test allocations; used heap should fall within seconds as GC runs.
- Use Copy results for tickets or before/after comparisons.
FAQ
Why is heap limit different from my system RAM?
The limit is per browser tab (JavaScript isolate), not total machine RAM. Desktop Chrome often caps near ~4 GB per tab regardless of 16 GB or 128 GB installed, to prevent one page from taking the whole machine.
Is this a replacement for MemTest86?
No. This measures browser heap behavior only. JavaScript cannot test DIMM hardware. Use MemTest86 bootable USB for physical RAM stability.
Why don't Firefox and Safari show heap stats?
performance.memory is a non-standard Chromium API. Other browsers hide it against fingerprinting. This tool tracks only what it allocates itself, capped at 300 MB.
What does Release & GC do?
It clears references to all test chunks so they become eligible for garbage collection. Used heap usually drops within a few seconds without a page reload.
When does allocation auto-stop?
When used heap exceeds 85% of jsHeapSizeLimit (Chromium), after 500 chunks, or at 300 MB self-allocated when performance.memory is unavailable.
Does data leave my browser?
No. All monitoring and allocation happen in this tab locally.
Introduction
Memory Test monitors how much JavaScript heap your browser tab is using — and optionally allocates memory in chunks to see how close you get to the tab’s hard limit before the browser stops the page.
On Chrome and Edge, the tool reads performance.memory every 500 ms:
- usedJSHeapSize → Used heap (MB)
- totalJSHeapSize → Total heap (MB) (reserved for this tab)
- jsHeapSizeLimit → Heap limit (MB) (ceiling before crash/OOM)
On Firefox and Safari, those fields are hidden. The tool still runs stress allocation but only tracks Allocated by test (MB) with a 300 MB safety cap.
This is not system RAM testing, not MemTest86, and not VRAM diagnostics.
How the test works
1. Live polling (500 ms)
A background timer calls readPerformanceMemory() and appends a point to the heap growth graph (up to ~60 seconds of history at 500 ms/sample).
2. Stress allocation
Start allocating repeatedly adds a Float32Array chunk (default 10 MB, configurable 1–100 MB) at your interval (50–5000 ms).
Each chunk touches first and last elements so the allocator cannot discard empty reservations.
3. Safety auto-stop
| Condition | When |
|---|---|
| 85% of heap limit | used / jsHeapSizeLimit on Chromium |
| 500 chunks | Regardless of browser |
| 300 MB self-allocated | When performance.memory is missing |
4. Release & GC
Release & GC clears the internal chunk array. Garbage collection is browser-scheduled — heap may drop over 1–5 seconds. Optional window.gc() runs only if exposed (some dev builds).
Understanding each output
Used heap (MB)
What it is: performance.memory.usedJSHeapSize — memory currently held by JS objects in this tab.
How to read it: Rises during allocation; should fall after Release & GC. A steady climb without releasing suggests a leak in this tab or another open app tab.
Total heap (MB)
What it is: totalJSHeapSize — memory the engine reserved for the isolate (≥ used).
How to read it: Often steps up in plateaus as the allocator grows pools. Large gap between total and used can mean fragmentation or reserved but unused space.
Heap limit (MB)
What it is: jsHeapSizeLimit — browser-enforced maximum for this tab’s JS heap.
Typical values: ~4 GB on 64-bit desktop Chrome; much lower on mobile (256–512 MB class).
Not measured: Physical RAM installed, OS free memory, or GPU VRAM.
Allocated by test (MB)
What it is: chunk count × chunk size MB held in references by this tool only.
How to read it: On Chromium, compare with Used heap rise — they should correlate. On Firefox/Safari this may be the only rising metric during stress.
Used / limit (%)
What it is: usedMb / limitMb × 100 when the API exists.
How to read it: Above 85% triggers auto-stop. Hitting 100% risks tab kill (“Aw, Snap!” / OOM).
Heap growth graph
| Line | Color | Meaning |
|---|---|---|
| Used heap | Green | usedJSHeapSize over time |
| Total heap | Yellow | totalJSHeapSize |
| Limit | Red dashed | jsHeapSizeLimit horizontal cap |
| Allocated only mode | Green | Self-allocated MB when no API |
What this test measures
| Measured | How |
|---|---|
| Tab JS heap usage trend | performance.memory polling |
| Proximity to tab OOM | Used / limit % |
| Effect of deliberate allocation | Chunk stress + graph |
| GC recovery after release | Used heap drop after Release |
What this test does NOT measure
| Not measured | Why |
|---|---|
| Physical RAM / DIMM errors | No hardware access from JS |
| Memory leak in other tabs | Only this tab’s heap API |
| Native app memory (Electron main, etc.) | Browser tab scope only |
| Swap / disk paging | OS-level |
| Accurate cross-browser heap compare | API missing outside Chromium |
Safety
- Use moderate chunk sizes on machines with little RAM or many tabs open.
- Auto-stop exists to reduce OOM tab crashes — not guaranteed in all edge cases.
- Do not use as production load testing against shared machines without permission.
- Release & GC before leaving the page if you allocated heavily.
Common use cases
1. How much headroom does this tab have?
Goal: See Used / limit % before loading a heavy SPA or local AI model.
Run: Open tool only — read live stats without allocating.
2. Suspected memory leak in your web app
Goal: Baseline this tool’s tab, then reproduce leak in another tab, return and compare Used heap after Release & GC here.
Note: Leak under test must be in the tab you are debugging — this tool does not read other tabs’ heap.
3. Before / after deploy
Goal: Same chunk settings, note peak Used heap and time to 85% stop — compare staging vs production build in same browser.
4. Explain “4 GB limit” vs 32 GB RAM to stakeholders
Goal: Screenshot Heap limit (MB) vs Task Manager system RAM.
5. Firefox / Safari developer
Goal: Use allocation mode only — confirm app logic tolerates growth up to 300 MB cap without relying on heap API.
Related tools
Pair this tab-heap monitor with other Device Tools checks:
- CPU Stress Test — multi-core Worker load; see whether CPU limits—not heap—are the bottleneck.
- GPU Stress Test — WebGL2 graphics stress and FPS stability.
- AI GPU Test — WebGPU readiness when large on-device models fail; check heap headroom here first.
- Device Info — coarse
deviceMemoryand environment context (not the same as per-tab heap limit).