Built for ML researchers and data scientists, ViewKit is one viewer for your data files. It reads and renders them right in the browser, so even huge or sensitive datasets stay on your computer.
Open .h5, .hdf5, .hdf, .he5, .nc files in your browser.
Open .parquet, .parq, .pq files in your browser.
Open .zarr (folder or .zip) files in your browser.
Open .csv, .tsv files in your browser.
Open .xlsx, .xlsm files in your browser.
Open .jsonl, .ndjson files in your browser.
Open .arrow, .feather, .ipc files in your browser.
Open .npy, .npz files in your browser.
Open .safetensors files in your browser.
Open .tfrecord, .tfrecords files in your browser.
Open .tar files in your browser.
Open .wav, .mp3, .flac, .ogg, .m4a files in your browser.
They stay on your computer. ViewKit reads and renders each file locally in your browser, so the contents are never uploaded or sent to a server. Once the page has loaded, you can even go offline.
It only reads the part you are looking at, straight from the file on your disk. Scroll to a new region and it fetches just those bytes, so multi-gigabyte files open in about a second.
HDF5 (.h5, .hdf5), Apache Parquet, Zarr (v2 and v3, as a zip or a dropped folder), Apache Arrow and Feather, CSV and TSV, Excel (.xlsx), JSON Lines (.jsonl/.ndjson), NumPy (.npy/.npz), safetensors, TFRecord, WebDataset (.tar) and audio files. More are added as people request them, so tell us what you need.
It is built for ML researchers and data scientists, who open files like these all day. The usual ways to peek inside one are a chore: write throwaway Python, spin up a notebook, or upload the file to some random site. We wanted to just look at a file the second we have it, without any of that, and without the data leaving the machine. So we built ViewKit.
No. There is nothing to install and nothing to sign up for. Open the viewer, drop a file in, and it opens.
Yes. Open as many files as you like.
We publish articles on how these formats are laid out on disk: Parquet row groups, Arrow's memory layout, chunk shape in HDF5 and Zarr, the safetensors header, and more. They are written from the specifications and cite them.
Use the feedback box at the bottom of this page, or email hello@viewkit.app. We prioritize the formats and features people actually ask for.
How these formats are laid out on disk, and the decisions that follow from it. Written from the specifications, with sources.
Why selecting one column can mean 200 separate reads, and what row group size actually trades off.
When to store Parquet, when to store Feather, and why converting between them costs a decode rather than a copy.
How a string column becomes three buffers, why a null costs one bit, and where the 64-byte padding comes from.
Why a 40 KB slice can cost 400 MB of I/O, and how to pick a chunk shape for HDF5 and Zarr.
Why Zarr writes chunks in parallel with no coordination while HDF5 needs an MPI build, and which to pick for object storage.
The renamed metadata fields, the single zarr.json, and the codec pipeline that replaced filters and compressor.
The complete layout in three fields, and why a pickle checkpoint can execute code while this one cannot.
Why float16 needs loss scaling and bfloat16 does not, with the bit layouts and ranges for both.
The header layout, the 64-byte padding rule, and why .npy can be memory-mapped but .npz cannot.
Sixteen bytes of framing per record, why there is no random access, and how to read one without TensorFlow.
How samples are grouped inside a tar, and why sequential shard reads keep the GPU fed.