Storage Read/Write Test
Free browser storage benchmark using IndexedDB and localStorage. Measure read/write MB/s, per-op latency and run multiple passes to see variance.
| Test Name | Speed | Avg (median) | Latency | Status |
|---|---|---|---|---|
| IndexedDB Write Write 1,000 items (1KB each) to IndexedDB | - | - | - | Pending |
| IndexedDB Read Read 1,000 items from IndexedDB | - | - | - | Pending |
| localStorage Write Write 100 items to localStorage | - | - | - | Pending |
| localStorage Read Read 100 items from localStorage | - | - | - | Pending |
| Large File Handling Read/Write 10MB file | - | - | - | Pending |
Storage Read/Write Test - Test Your Disk Performance
A comprehensive online storage speed testing tool that measures browser storage performance using IndexedDB and localStorage. Run tests for write speed, read speed, and large file handling to evaluate your system's storage performance and browser database efficiency.
How does storage speed testing work?
Storage speed testing measures browser storage performance by executing read and write operations:
1. IndexedDB Write: Tests writing 1,000 items (1 KB each) to IndexedDB
2. IndexedDB Read: Measures reading 1,000 items from IndexedDB
3. localStorage Write: Tests writing 100 items to localStorage
4. localStorage Read: Measures reading 100 items from localStorage
5. Large File Handling: Tests reading/writing a 10 MB Blob
Each test calculates throughput (MB/s) and latency (ms per operation). Higher MB/s and lower latency indicate better performance.
What is IndexedDB vs localStorage?
IndexedDB and localStorage are browser storage systems with different characteristics:
localStorage:
- Simple key-value storage
- Synchronous API (blocks the main thread)
- Limited to ~5-10 MB per origin
- Stores strings only (objects must be JSON-stringified)
- Good for small UI state
IndexedDB:
- Full database with indexes and cursors
- Asynchronous API (non-blocking)
- Much larger quota (often gigabytes)
- Stores structured clones (objects, Blobs, ArrayBuffers)
- Best for large datasets and offline apps
This test measures both so you can compare their real-world cost on your device.
What affects storage speed?
Several factors influence browser storage performance:
- Disk Type: SSD >> HDD
- Disk Interface: NVMe > SATA SSD > eMMC > HDD
- Available Space: Drives over 80 % full slow down (TRIM and over-provisioning shrink)
- Browser Engine: Chromium uses LevelDB-backed IndexedDB; Firefox uses SQLite
- Operating System: File system journaling, fsync behavior, and page cache size matter
- Background Processes: Antivirus or backup I/O contention slows reads/writes
- RAM: More free RAM means better OS page caching
For accurate results, close other applications and ensure ample free disk space.
What is a good storage speed score?
Understanding browser storage speed results:
Typical speeds by storage type:
- NVMe SSD: 50-200+ MB/s in browser (3-7 GB/s raw)
- SATA SSD: 20-100 MB/s in browser (550 MB/s raw)
- Fast HDD (7200 RPM): 5-20 MB/s
- Slow HDD (5400 RPM): 2-10 MB/s
- Mobile eMMC/UFS: 10-50 MB/s
Note: Browser overhead and JavaScript boundaries make these speeds 10-100x slower than native disk I/O. Latency below 1 ms is also important for responsive UI.
Why test browser storage?
Browser storage testing is valuable because:
- Web App Performance: Shows how fast web apps can store/retrieve data
- Progressive Web Apps (PWAs): Critical for offline-capable apps
- Browser Caching: Affects page load times and Service Worker behavior
- Debugging: Identify storage bottlenecks before users complain
- Comparison: Benchmark different browsers and devices side-by-side
This test reflects real-world performance for any web app that relies on browser storage APIs.
Why are my IndexedDB writes slower than reads?
IndexedDB writes typically run 2-10x slower than reads because every write must:
1. Acquire an exclusive lock on the object store (readonly reads use shared locks)
2. Update any secondary indexes you defined (each index = extra B-tree write)
3. Append to the write-ahead log for durability
4. Flush to disk on transaction commit (fsync)
Reads, by contrast, often hit the OS page cache and return without touching disk. To accelerate writes: batch many puts in a single transaction (commits amortize fsync), avoid unnecessary indexes, and use put() with explicit keys instead of autoIncrement.

What is the browser's storage quota and what happens when I hit it?
Modern browsers grant origins a quota based on free disk space and the storage policy. Typical limits:
- Chrome/Edge: up to 60 % of free disk per origin
- Firefox: up to 50 % of free disk (group quota)
- Safari: 1 GB without prompt, then user permission required
Query your live limit with navigator.storage.estimate(), which returns {quota, usage} in bytes. When you exceed quota, IndexedDB transactions abort with QuotaExceededError and localStorage throws on setItem(). Persistent storage via navigator.storage.persist() prevents the browser from auto-evicting your data under disk pressure.
Why does the 10 MB file test sometimes fail on mobile?
Mobile browsers cap several limits that can break the 10 MB Blob test:
1. String size: localStorage stringification of a 10 MB Blob doubles to 20 MB UTF-16; iOS Safari rejects strings above 16 MB.
2. Heap pressure: mobile Chrome heap is 256-512 MB; allocating a Blob plus copying it for IndexedDB can OOM the tab.
3. Origin quota: low-end Android devices with 8 GB internal storage may only grant 100-500 MB per origin.
4. Background eviction: if you switch apps mid-test, iOS may discard the tab and the transaction silently aborts.
For reliable mobile testing, free at least 2 GB of device storage and keep the browser foregrounded. This tool now uses a fixed-size binary Blob (real bytes) instead of a giant UTF-16 string, so it is much lighter on memory.
Which browsers and devices support these tests, and are results comparable?
Support matrix and comparability:
- Chromium (Chrome/Edge/Brave/Opera): IndexedDB on LevelDB, localStorage on LevelDB. navigator.storage.estimate() supported.
- Firefox: IndexedDB on SQLite, localStorage on SQLite. estimate() supported.
- Safari/iOS WebKit: IndexedDB on SQLite, stricter quotas and string limits; estimate() limited.
- Old Android WebView / IE: partial or no IndexedDB.
Because each engine uses a different storage backend (LevelDB vs SQLite), absolute MB/s figures are NOT directly comparable across browsers. Compare the SAME browser on different devices, or the same device across browsers only as a rough guide. Always note the browser/UA (the export includes it) when sharing numbers.
Is this the same as my SSD or HDD speed? Can I use it for disk certification?
No. This measures BROWSER STORAGE throughput, not raw disk speed. The numbers pass through JavaScript, the storage engine (LevelDB/SQLite), the OS page cache, journaling and fsync, so they are typically 10-100x slower than native disk I/O and are heavily influenced by caching. Do NOT use these results to certify or grade an SSD vs HDD, validate drive RMA, or quote vendor benchmark numbers. Use a native tool (CrystalDiskMark, fio, dd) for raw media certification. This test is for diagnosing web-app storage behavior and spotting a genuinely failing/slow eMMC versus cache jitter via repeated runs.
Is my data uploaded? Is this private and secure?
The test is 100% local. It runs entirely in your browser, writes only to the current origin's sandboxed storage, and automatically deletes the test IndexedDB database after each run. Nothing is sent to any server and no telemetry is collected. CSV/JSON export happens client-side via a Blob download. Note that navigator.storage.estimate() and navigator.storage.persist() require a secure context (HTTPS); on plain HTTP the quota/usage fields may read 'Unknown' even though the read/write tests still work.
How do I run multiple passes and export results for a QA ticket?
Browser storage I/O is noisy (page cache, background I/O, garbage collection), so a single pass is unreliable. Pick 3 or 5 in the Runs selector before pressing Start: the tool repeats the whole suite and reports min, max, average and median per test so you can see variance and distinguish a genuinely slow/failing eMMC from cache jitter.
After a completed session, Export CSV and Export JSON buttons appear. The file includes a header block (device user agent, timestamp, requested runs, storage quota/usage) plus every per-run speed and latency and the per-test stats. Attach it to a repair ticket or use it to compare devices side-by-side with reproducible evidence.
Key Features
- 5 comprehensive storage speed tests
- IndexedDB write and read benchmarks
- localStorage write and read tests
- Large file (10MB) handling test
- Auto-scaling speed measurement (B/s to GB/s)
- Latency measurement in milliseconds
- Multi-run min/max/avg/median statistics
- Export results to CSV and JSON
- Storage quota and usage display
- Average write and read speed calculation
- Individual test timing and scoring
- Visual progress indicators
- Stop test anytime
- Automatic cleanup after tests
- 100% client-side - no data uploaded
- Works offline
- Mobile and desktop support
- Dark mode compatible
