Snapshot Viewer for Redis and Valkey RDB Files
Open a Redis or Valkey snapshot, the dump.rdb file, and see what’s in it: keys by type and database, the biggest keys, the prefixes that take the most space, how long expiring keys have left, and every value. It also reads the payloads of the DUMP command. It all runs in your browser.
Nothing you load leaves this page. The tool doesn’t send anything anywhere, and the page’s security policy stops it from fetching or loading anything from another site, so your data stays on your machine.
On a wide screen you can open it full screen.
How to Use It
- Get a snapshot. Copy the
dump.rdbfrom the server’s data folder (CONFIG GET dirsays where it is), use a backup, or ask a running server for a fresh one over the network:
redis-cli -h 10.0.0.4 -p 6379 --rdb dump.rdb
valkey-cli -h 10.0.0.4 -p 6379 --rdb dump.rdb
- Open it. Choose the file or drop it on the page. It’s read in steps, with a progress bar.
- Read the totals. Keys and bytes by type and encoding, the biggest keys, prefixes, expiries, and idle times or access counters when the server’s memory policy records them.
- Browse. Filter by part of a key name or by type, and pick a key to see its value.
- Take it with you. Download every key as CSV, or just the key names for the Keyspace Map.
--rdb makes the server fork and write a fresh snapshot, as it does for a new replica, which needs spare memory on a busy primary. A replica or an existing backup is the gentler choice.
What’s in a Snapshot
Redis and Valkey keep everything in memory and write it all to a file from time to time, so the data survives a restart. Replicas get their first copy in the same format, and DUMP returns one key’s value in it. The file is a list of records: a header with the format version, fields about the server, and then every key with its expiry, its type and its value, ending with a CRC64 checksum.
Reading the file instead of the server has one big advantage: it costs the server nothing. --bigkeys, MEMORY USAGE and SCAN all run against a live server, often the production one. A snapshot answers the same questions offline.
The format has split in two. Redis 7.4 moved to version 12 and Redis 8.10 writes version 15, adding hash fields with their own expiry, arrays, hash templates and new stream features. Valkey 9 jumped to version 80, with its own header and its own layout for hash field expiry. Type numbers from 22 up mean different things in each, so the viewer reads the header first and decodes accordingly. It reads snapshots from Redis 2.6 through 8.10 and Valkey 7.2 through 9.1.
How It Was Tested
Seven real servers, built from source, loaded the same dataset and saved a snapshot: Valkey 9.1.2 and Redis 8.10.2, 7.2.16, 6.2.24, 5.0.14, 3.2.13 and 2.8.24. Then each server was asked about every key through ordinary commands.
- For all 234 keys, the viewer’s value, type and expiry matched the server’s answers, and so did the encoding of every hash, list, set and sorted set.
- The bytes it counts for each value matched
DEBUG OBJECTon every server, apart from two cases where Redis 8.10.2 reports a different size than it writes: template hashes, and hashes with field expiries. - Every key’s
DUMPpayload decoded to the same value with a correct checksum. - LFU counters matched
OBJECT FREQfor all 77 keys of a Valkey snapshot, and idle times were within 2 seconds ofOBJECT IDLETIMEfor all 105 keys of a Redis one.
Snapshots from cluster nodes, a file written without a checksum and an append-only file that starts with a snapshot read correctly too.
The Code
The viewer’s logic is one JavaScript file with no dependencies, open source under the Apache License 2.0. It runs as this page, as a command line in Node.js that reads files of any size piece by piece, and inside your own code:
node snapshot/cli.js dump.rdb
node snapshot/cli.js dump.rdb --key user:42
node snapshot/cli.js dump.rdb --keys > keys.csv
The full manual, the tests and the snapshots they replay are in the snapshot folder on GitHub. The other tools work the same way.