CrystalDiskMark measures how quickly a storage device reads and writes test data. It creates a temporary test file on the selected drive, runs sequential and random workloads, and reports throughput, operations per second, or latency. The program does not inspect drive health, predict failure, or make the disk faster. It measures one configured workload under the conditions present during that run.
Pick the target
The main window asks for a drive, test-file size, and number of runs. Clicking All performs every displayed test, while a button beside one row runs only that workload. This matters when the target is a slow USB stick: a complete set with a large file and several repetitions can take far longer than one focused measurement.
CrystalDiskMark writes its temporary data to the selected volume. Running repeated tests therefore adds writes to an SSD or flash drive, and the project’s own notice warns that benchmarking can shorten flash-memory life. One deliberate run is more useful than refreshing the result until a preferred number appears.
Read the rows
Sequential tests move large blocks in an ordered stream. They resemble work with large contiguous files more closely than random tests. Random tests use small blocks at scattered locations and expose storage behavior under many small requests. Queue and thread values describe how many requests the benchmark keeps active, not how many files a normal program will always handle at once.
CrystalDiskMark can show MB/s, GB/s, IOPS, or average latency in microseconds. Throughput makes large-file movement easy to compare. IOPS and latency explain small-request behavior better. The displayed MB uses one million bytes rather than the binary MiB unit, so another benchmark that labels units differently can appear to disagree even when both measured similar data.
Profiles change the workload
Default, NVMe SSD, Peak Performance, and Real World Performance profiles use different block, queue, and thread settings. A Peak result should not be placed beside a Real World result as if both came from the same test. CrystalDiskMark also warns that results from different major releases may not remain compatible.
The test-data choice can use random bytes or zero-filled data. Some controllers compress repeated zeros, which can raise a zero-fill result above a random-data result. CrystalDiskMark labels the setting, but a copied number loses that context unless the user records the selected profile and data pattern with it.
Conditions affect results
Test size, file position, free space, fragmentation, controller, CPU load, temperature, and background activity can change the result. A short test may fit partly inside a device cache. A longer test can expose sustained behavior after that cache fills. Neither number is false, but each answers a different question.
Thermal throttling can lower later runs on a hot NVMe drive. Antivirus scanning, an operating-system update, or another file copy can compete for the same disk. CrystalDiskMark does not isolate the computer from those tasks. Comparable measurements need the same profile, test size, power mode, drive state, and quiet background.
Network drives need care
When CrystalDiskMark starts with administrator rights, it does not show mapped network drives. The official manual directs users to run without elevation when they need to select one. A network-drive result combines server storage, network latency, protocol behavior, and local caching, so it is not a direct measurement of the remote disk alone.
The program can copy a result or save it as text or an image. A useful record includes the drive identity and capacity beside the profile, test size, unit, and data pattern. Without those details, the columns remain numbers from an unknown workload rather than a repeatable benchmark.
