No installs. Open anything, no matter the size. Share instantly.
A 40 GB firmware image opens in a browser tab — instantly, because nothing is loaded until you look at it. Then you send an invite, and someone is in the bytes with you. Neither of you uploaded a thing or installed an app.
No install · No account* · Your file never leaves your machine
Open
Other tools read the whole file into memory and hand you a progress bar — or a “file too large” warning. ByteSlicer reads a block at a time, only where your eyes are. The size of the file stops being a number you have to care about.
This is the load-bearing claim of the whole product, and it is the one part that is already demonstrable: an 8 GiB file verified in Chrome and Safari — at offset 0, at 1 GiB, past the 32-bit line, and at EOF — from the same codebase that builds native.
Understand
Apply a format description and the flat bytes become a navigable tree — fields named, offsets highlighted, nested records walkable. Click a field, the hex jumps and highlights. Click a byte, the tree tells you what you just touched.
Together
Same offsets, same structure tree, each other’s cursors and selections moving live. The person joining doesn’t have the file and never gets a copy of it — the blocks they look at stream from your machine to theirs, peer to peer, as they scroll.
Cursors, selections and a live map of the file down the side of the view — one marker per person, click it and you’re where they are.
Name a range. Everyone in the session sees it, and it survives the session — the note is part of the record, not part of the chat.
Bytes go directly between people. Our servers introduce you and then get out of the way — which is also why there is nothing for us to leak.
Remember
Edits aren’t written over the original — they’re recorded. What persists is the ledger: every change, annotation and author, bound to the original by its content hash. Kilobytes, not gigabytes. Encrypted end to end, so even we hold nothing but ciphertext.
Never uploaded
Malware samples breach terms of service. Client firmware is under NDA. A forensic image is evidence with a chain of custody. For most of the people who need collaborative binary analysis most, “upload it to our cloud” ends the conversation. So we don’t.
Read block by block from local disk. No copy, no cache on anyone’s server, no “temporary” upload that quietly persists.
When a teammate scrolls, the blocks they’re looking at travel straight from your machine to theirs — checked against a hash on arrival.
Annotations say things like “AES key at 0x4F00”, so the record is encrypted before it is stored. Designed in from the start — it cannot be retrofitted credibly.
Everywhere
The same C++ builds to WebAssembly and to a native app — same UI, same file, same session. A browser can’t read another process’s memory or open a raw socket, and we don’t pretend otherwise. The half that must be frictionless works everywhere; the privileged half is local, where it belongs.
| Capability | Web | Native |
|---|---|---|
| Open and inspect a file of any size | Yes | Yes |
| Format definitions and structure view | Yes | Yes |
| Join a shared session | Yes | Yes |
| Recorded history, annotations, persistence | Yes | Yes |
| Pipes, sockets, live process memory | — | Yes |
| Command line and scripting | — | Yes |
A byte source is an abstraction, not a file path. Inspecting a live stream, a socket, or a running process’s memory is the same operation as inspecting a file — which is the difference between a hex editor and an inspection tool.
Who it’s for
Consultancies auditing client hardware under NDA, onboarding an analyst onto a blob nobody has seen before — several times a week, billed by the hour.
Evidence images that must not move, and an attributable, non-repudiable record of who examined what and when — the shape of a chain-of-custody argument.
Samples that breach terms of service the moment they touch a third-party cloud, worked on by two people who need to be looking at the same offset.
Undocumented save files, proprietary telemetry, ancient disk images. The work is guessing a structure together and writing it down as you go.
Splitting a firmware image four ways under time pressure, or walking a student through a header while they watch your cursor move.
Automotive, medical and industrial suppliers who increasingly have to show their working — a reviewable record of what was in the artifact and who checked it.
A day with it
Today, bringing a colleague onto an unfamiliar blob means screenshots, offsets recited over a call, and a 4 GB file transfer that ends in a policy violation. Instead you send a link. They’re at your offset in seconds, seeing your cursor, with nothing copied anywhere.
Three people work one image through the night. Every annotation, every patch, every conclusion lands in one attributable record — so the report writes itself from the ledger, and next quarter someone can ask what was at that offset and get an answer.
Flip a byte, fix the checksum, reconstruct the modified image, and show the client exactly which bytes you touched and why — reconstructed from a record that is kilobytes, next to a file you never had to move.
One writes the format definition while the other tests it against real records, both watching the same tree resolve. What used to be a private, undocumented hunch becomes a shared artifact your whole team inherits.
The honest comparison
The competition in the field is fierce. What none does is put a second person in the file with you and keep the record afterwards — because collaboration can’t be bolted on to a single-player tool. It is a commitment in the data model that reaches through every layer of the application.
| Tool | Structure | Huge files in a browser | Shared session | Recorded history |
|---|---|---|---|---|
| ByteSlicerfutonica | Kaitai formatshundreds, community-maintained | Demand-paged40 GB opens instantly | Live, peer-to-peercursors, presence, no upload | Encrypted ledgerattributed, replayable, versioned |
| ImHexfree, open source | Pattern languageexcellent, its own DSL | Loads it allits web build reads the whole file into memory first | Single player | Undo, not history |
| 010 Editorcommercial | Binary templatesmature, two decades of them | Desktop only | Single player | Per-file, local |
| Kaitai Web IDEfree | Authoring-firstbuilt to write .ksy, not to analyse | In-memory | Single player | None |
| HxD, Hex Fiendfree | None to speak of | Desktop only | Single player | None |
| Ghidra, IDA, Binary Ninjadisassemblers | Code, not dataa different problem entirely | Desktop only | Mostly asynchronous | Project databases |
ImHex is free, excellent, and years deep in single-player features. We compete where a single-player tool structurally cannot follow: the second person, and the record.
Not just that a 40 GB image opens — that everything after it opens stays fast. Paging, navigation, structure and sharing are all built around never holding the whole file, on the exact platform where the strongest incumbent loads it into memory.
You choose where the record lives — our storage, your own git remote, or a file on your disk — and it is written in formats you can read without us: open format definitions, an exportable ledger, a binary you can reconstruct from a command line.
Plans
The line isn’t editing — it’s history. The free tier has to be good enough to be your default editor, or it isn’t doing its job.
Introductory pricing, in USD. ByteSlicer is early — the prototype is free and open to anyone right now, and the paid tiers arrive as the capabilities above do.
Right now, in this browser
Open the prototype, pick the largest binary on your disk, and watch it appear. Then send someone the link and scroll it together. Nothing installs and nothing uploads.
Open ByteSlicer →futonica.com/byteslicer