Memory Benchmark
Measure typed-array allocation and read/write throughput in your browser, and see what memory figures your browser actually exposes.
Browser-reported memory
navigator.deviceMemory
Not exposed by this browser
JS heap (performance.memory)
Not exposed by this browser
Chromium browsers round deviceMemory to one of 0.25, 0.5, 1, 2, 4 or 8 GB, and it can be lower than your real RAM. Firefox and Safari do not expose either figure, which is normal and not a bug.
Throughput benchmark
Allocates and reads/writes typed arrays in JavaScript to estimate practical memory speed.
Quick guide: how to use the Memory Benchmark
Takes under a minute- 1Close memory-hungry tabs so the browser can allocate freely.
- 2Run the benchmark and let every phase finish.
- 3Check allocation, read and write throughput separately.
- 4The reported heap limit is a browser cap, not your total RAM.
Overview
Memory speed rarely gets attention the way CPU clock speed or GPU model does, but it quietly affects everything a computer does. Every instruction a processor runs eventually needs to read or write data somewhere, and if that data has to travel through slow memory, even a fast CPU ends up waiting. This test gives you a browser-based look at how quickly JavaScript can allocate memory and move data through it, plus whatever memory figures your specific browser is willing to expose.
The benchmark works with typed arrays, specifically Float64Array buffers, which are JavaScript's closest equivalent to raw memory blocks. It times four distinct operations: how fast new arrays can be allocated, how fast data can be written to an array in order, how fast that same data can be read back in order, and how those speeds change when the memory access pattern is randomized instead of sequential.
Alongside the throughput numbers, this page reads two browser-exposed figures when available: navigator.deviceMemory, a rough approximation of total system RAM, and performance.memory, which reports the JavaScript heap's current and maximum size in Chromium-based browsers. Both come with real limitations that are worth understanding before drawing conclusions from them.
How to read your results
Allocation throughput
This measures how many megabytes per second your browser can carve out of memory for new arrays. It's influenced by the JavaScript engine's memory manager and garbage collector as much as by raw hardware, so differences here often say more about the browser than the RAM chips themselves.
Sequential vs random access
Sequential read and write numbers should be noticeably higher than random read and write numbers, and that gap is normal and expected on every computer due to how CPU caches work. A very small gap between sequential and random speeds can actually indicate a very fast processor cache relative to memory size, not a problem.
deviceMemory and heap figures
Treat navigator.deviceMemory as a rough tier indicator rather than an exact RAM figure, since Chromium caps it at 8GB regardless of how much RAM is actually installed. The JS heap numbers reflect what's allocated to this specific browser tab right now, and will grow as the page and its tools run, which is expected behavior rather than a memory leak.
Troubleshooting
deviceMemory or heap figures show 'Not exposed'
This is expected in Firefox and Safari, which don't implement these APIs at all for privacy reasons. Switch to Chrome, Edge, Brave, or another Chromium-based browser if you specifically need to see these numbers.
Throughput numbers seem unusually low
Close other memory-heavy tabs, especially ones with large images, videos, or many open tabs from the same site, since they compete for the same JavaScript heap space and physical RAM. Restarting the browser fully, rather than just closing tabs, clears accumulated memory fragmentation that can also slow things down.
Browser tab crashed or became unresponsive during the test
This can happen on devices with very little free RAM, since the benchmark needs a few hundred megabytes of headroom to run its typed arrays. Close other applications and tabs to free memory, then try again with fewer things running simultaneously.
What browsers deliberately hide, and why
Detailed memory information can be used to fingerprint a device, since exact RAM amounts combined with other signals narrow down which specific device model someone is using. Because of this, no browser exposes exact RAM in gigabytes, exact memory speed in MHz, or memory channel configuration. Chrome compromises by rounding deviceMemory into six broad buckets, while Firefox and Safari remove the API entirely rather than risk it being used for tracking.
This means a browser-based memory test can never fully replace tools like Task Manager, Activity Monitor, or a manufacturer's system information panel for checking exact installed RAM. What it's good for instead is measuring practical throughput and comparing that throughput across browsers or after a hardware change, like adding a RAM stick or upgrading to a faster memory kit.
When memory is actually your bottleneck
If your computer feels slow specifically when you have many browser tabs or applications open at once, and speeds back up after closing some of them, that's a classic sign memory capacity, not speed, is the constraint. If instead everything feels sluggish even with few things open, and this benchmark's throughput numbers are dramatically lower than what's typical for similar hardware, that points more toward a memory speed or configuration issue, like RAM running in a slower mode than it's rated for.
- Check installed RAM amount and speed in your OS's system information panel, not just this browser test.
- Compare this test's numbers before and after closing background applications.
- Pair this test with the CPU and storage benchmarks on this site to rule out other bottlenecks.
Frequently asked questions
Can a website actually measure my RAM speed?
A website can measure how fast JavaScript can allocate and access typed arrays, which correlates with real memory speed but also includes overhead from the JavaScript engine, garbage collector, and CPU cache behavior. It's a useful practical measure, not a lab-grade memory bandwidth test like you'd get from dedicated hardware diagnostic software.
Why does navigator.deviceMemory show a lower number than my actual RAM?
Chromium-based browsers deliberately round and cap this value to one of a small set of numbers (0.25, 0.5, 1, 2, 4, or 8 GB) as a privacy measure, so a system with 32GB of RAM will still report a maximum of 8. This is intentional and not a sign of a problem.
Why don't Firefox or Safari show deviceMemory or performance.memory at all?
Both browsers choose not to implement these APIs, largely over concerns that detailed memory information could be used to fingerprint or track users across sites. If you need this information, Chrome, Edge, or another Chromium-based browser will show it.
What's a normal read/write speed to see in this test?
Sequential read and write speeds in the low thousands of MB/s are common on modern hardware, since this measures on-heap array access rather than physical RAM chip bandwidth directly. Random access speeds are typically noticeably lower than sequential speeds because of CPU cache misses, which is expected and not a fault.
Why is random access slower than sequential access?
CPUs read memory in cache-line-sized chunks and predict sequential patterns well, so consecutive memory addresses load quickly from cache. Randomly scattered addresses defeat that prediction and force more trips to slower main memory, which is a fundamental property of computer memory hierarchies, not a browser limitation.
Does closing other browser tabs improve my score?
Yes, especially tabs that hold large amounts of data in memory already, since they compete for the same physical RAM and can force garbage collection pauses during the test. Closing unrelated tabs before running the benchmark gives a cleaner, more repeatable result.
What does performance.memory.jsHeapSizeLimit actually mean?
It's the maximum heap size the JavaScript engine will allow for this page before it starts aggressively garbage collecting or throwing out-of-memory errors, not the total RAM in your system. It's typically a few gigabytes even on machines with much more physical RAM, since it's a per-tab safety limit.
My allocation throughput number seems inconsistent between runs. Why?
Garbage collection timing is not perfectly predictable, so if a collection cycle happens to run during the timed allocation loop, that run will show lower throughput. Running the benchmark two or three times and looking at the typical result rather than a single outlier gives a more reliable picture.
Can this test tell me if my RAM is faulty?
Not reliably. This benchmark measures throughput and speed trends, but detecting faulty RAM requires exhaustive bit-pattern testing tools like memtest86 that run outside the browser and check every memory address directly. If you suspect a hardware fault, use a dedicated memory diagnostic tool instead.
Does more RAM always mean a better score here?
Not directly. This test allocates a fixed, modest amount of memory well within what almost any modern device has available, so it measures access speed rather than total capacity. A device with less total RAM but faster memory chips can outscore one with more RAM but slower chips.