Open a disk image online without uploading it
Most online disk image viewers upload your evidence to a server. Here is how to read one in the browser with nothing leaving the machine, and how to prove it.
Search "open E01 online" and most of what you get will quietly upload your image to a server. The page takes your file, POSTs it somewhere, parses it there, and streams back a tree. For a disk you found on eBay, who cares. For evidence, that is a disclosure you did not authorize, to infrastructure you do not control, governed by a privacy policy you did not read.
The thing is, none of that uploading is necessary. Parsing a disk image is pure computation over bytes you already have. The only reason it ends up on a server is that the server is where the developer put the parser.
What "upload" actually costs you
Think about the threat model, not the convenience. The moment an image leaves the machine you control, several things happen that you cannot take back.
The bytes hit a TLS-terminating endpoint, which means they are plaintext in that server's memory, and possibly its logs. They may be written to temp storage to be parsed, and "deleted afterwards" is a promise, not a guarantee, and certainly not one you can prove to a court. If the service is on a CDN or a cloud provider, your evidence just became subject to that provider's jurisdiction and their lawful-access regime. And you have created a copy whose existence you now have to account for in your chain of custody.
For an attacker or a curious operator on the other end, an uploaded forensic image is a gift. It is, by definition, the most sensitive data from a system someone cared enough to image. Credentials in unallocated space, the file slack full of document fragments, the lot.
None of this is hypothetical handwringing. It is the default behavior of most "online" forensic tooling, and it is why a lot of shops ban web tools outright. They are usually right to, given what those tools do.
Doing the parsing where the data already is
The alternative is to ship the parser to the browser instead of shipping the image to the parser. Disk Image Parser compiles a Rust disk-image parser to WebAssembly and runs it in the tab. You drop a file and the same code that would run server-side runs locally, against the File object the browser already holds. Nothing is sent.
You can verify this in about five seconds, which is the part I like. Open the network tab, drop a 4 GB image, browse around, export a file. The image bytes never appear as a request. The only network traffic is the page itself and the WebAssembly module, both fetched once and cached. If you see your image going out, the tool is lying, and you should be able to tell.
A content security policy backs it up at the platform level. The page runs under a CSP that permits WebAssembly execution and a same-origin worker but does not need a permissive connect-src for uploading evidence anywhere. The browser sandbox is doing the enforcement, not a promise in a footer.
How it reads a 20 GB image in a tab without dying
This is the part that sounds impossible and is just engineering. WebAssembly is a 32-bit address space, so naively you cannot even hold a 5 GB image in memory, let alone a 50 GB one. You do not hold it.
The dropped file stays on disk. In a web worker, FileReaderSync returns arbitrary byte ranges of the File synchronously, with no copy and no storage-quota games. The parser asks for the bytes it needs, a boot sector here, an MFT record there, and the worker serves that range straight off the file. Offsets are tracked as 64-bit values so the four-gigabyte address ceiling never bites.
E01 is the interesting case because the data is compressed. The reader builds the chunk offset table up front, then decodes individual chunks on demand and caches the recent ones. Browse into a directory and it decompresses the handful of chunks covering those records, not the whole image. So a 30 GB E01 is navigable with a footprint measured in megabytes.
Where it gets honest about limits: a few operations want the whole image, like computing a full-image MD5 for hash verification or carving across a multi-gigabyte range. Those stream the image through in windows rather than materializing it, but they take as long as reading the file takes, because physics. Browsing and per-file export stay cheap.
The one thing the browser does not replace
Reading an image read-only in a browser is safe. The page cannot write back to a file it opened, and there is no path from a tab to a raw block device. That covers analysis.
It does not cover acquisition. When you image physical media, you still need a write blocker so the act of reading the drive does not change it. A browser is irrelevant to that step because it never touches the drive in the first place. Image the media properly, with the right hardware, then do the reading wherever is convenient, including a tab.
If the workflow is "I have an E01 and I need to look inside it without it leaving this laptop," the upload was never required. Open it locally and watch the network stay quiet.