Byte Lab
2026 · Rust · WebAssembly · WebGL · How this site works
Every file is a row of bytes, numbers from 0 to 255, and every format is a way of arranging them. A hex editor shows them sixteen at a time, which is how you read a file but not how you see one. The Byte Lab shows the whole file at once, four ways: a map that folds the bytes into a square, a cloud that turns every three bytes into a point, a strip of how random the file looks from start to end, and the parts its own format says it has. Drop in anything, a photo, a program, a save game, a PDF, or open one of the samples, which are all files this site already serves. Nothing is uploaded: the file never leaves your browser.
The map
A file is a line, and a screen is a square. Wrapping the line into rows, the way a hex editor does, breaks it: bytes that sit side by side in the file end up a whole row apart. The map folds it along a Hilbert curve instead, a path that fills the square without ever jumping, so bytes that are close in the file stay close on the map and a run of them fills a block rather than a stripe. Aldo Cortesi made the case for it in 2011, comparing curves for exactly this, and the colours follow his: black for zeros, white for 0xFF, green for control codes, red for everything above 127, and, here, the site's yellow for printable text. A small file gets a cell per byte; a big one gets a slice per cell, coloured by its mix.
entropy colours the same map by how unpredictable the bytes around each cell are, from none, where they're all alike, to eight bits a byte, where every value is as likely as any other. Text sits around four or five bits, machine code around six, and compressed or encrypted data right at the top, because squeezing every pattern out is what compression does. So a bright block in an otherwise dim file is something packed: a picture inside a document, a compressed stream, now and then something hidden. parts colours the map by the format's own layout instead.
The cloud
The cloud takes the bytes three at a time, the first, second and third, then the second, third and fourth, and so on, and plots each triple as a point in a cube, one byte on each axis. It's the idea Christopher Domas showed in ..cantor.dust.. in 2012, and it works because every kind of data leaves its own shape. Text huddles in a small block, where the letters' codes are. Compressed data fills the whole cube evenly, a fog with no shape, since no triple is likelier than any other. Machine code draws lines and planes, instructions repeating with small changes. And sound draws curves: three samples in a row of a pure tone always lie on an ellipse, and the higher the tone, the wider the ellipse opens, so the wav sample, a tone rising from a hum to a whistle, becomes a twisting ribbon. pairs flattens the cube into the classic square: a byte across, the next one up.
The parts
The parts tab is the file as its own format describes it, a tree of the pieces it was built from. These include a PNG's chunks; a JPEG's markers and each scan of a progressive one; a PDF's objects and the streams inside them; and a WebAssembly module's sections, down to each function's body. Programs for Linux, macOS and Windows show their headers, load commands and sections, both halves of a universal binary included. A WebM shows its elements, an MP4 its boxes and a font its tables. A SQLite database shows its pages, named after their tables, and a ZIP its files, named as the Word document, spreadsheet or EPUB it really is. Dozens more formats, from TIFF and MIDI to 7z and Java classes, get at least their header and body marked. A file that reads as text is split the way it's written: a JSON array by item, Markdown by heading, CSV by row. Pick a part and it lights up everywhere at once, on the map, the strip and the cloud. That shows you where a program's code ends and its data begins, or what one scan of a JPEG looks like as triples. parts on the map and part in the cloud colour every byte by the kind of part that holds it: header, metadata, code, data, compressed or text.
The hex tab reads the bytes themselves, coloured like the map, and under it the bytes at the cursor are read as numbers: integers and a float, little- or big-endian. The text tab lists every run of readable characters, in ASCII or in the UTF-16 Windows uses, leaving out the short runs that turn up by chance inside compressed data.
How it's built
The engine is a Rust crate with no dependencies, compiled to a 740 KB WebAssembly module with no bindings, like the other labs'; nearly all of that is the parsers. The file is copied into its memory in chunks, so the page never holds two copies, and anything up to 256 MB fits. It measures any slice of the file on request: entropy through a window slid along the bytes, so each byte goes in and out of it once; the mix of byte kinds; the parts; the text. The page only paints, so switching modes is instant.
The cloud is WebGL2, and the bytes go to the graphics card as they are. The trick is a vertex attribute that reads three bytes but steps forward one, so every triple in the file becomes a point without the page building a single one. The points add up as light in a floating-point buffer and are only then turned into colour, which is why a dense cluster glows instead of clipping to a white blob.
Some formats never say how long a part is. A gzip file, for one, simply stops, so the engine inflates the compressed stream just to find where it ends. Every parser reads through checks that stop at the end of the file. Each is tested against every truncated and scrambled copy of its sample, and the whole set against thousands of real files and over a hundred thousand mangled ones. The files people drop in are exactly the odd ones, and in WebAssembly a single read past the end would stop the engine dead. A file can't travel in a link, so a link only keeps which sample you opened and how you were looking at it.
Back to Labs · see sound as a picture in the Spectrogram Lab · read a game's own files in Deus Ex in the Browser · see how this site works.