Do I need to install anything to read a $I file?

No. This site parses $I files in your browser via WebAssembly — drag the file onto the home page and the original path, size, and deletion time appear instantly. Nothing is uploaded.

What is the standard command-line tool for $I files?

RBCmd by Eric Zimmerman. Run 'RBCmd.exe -d C:\$Recycle.Bin --csv .' to recursively parse every $I file into a CSV ready for Timeline Explorer.

Can I parse a whole $Recycle.Bin folder at once?

Yes — drop multiple $I files onto the parser at once, or point RBCmd at the folder with -d. Each row maps one deleted item.

Why does my $I file fail to parse?

Common causes: it's actually a $R content file (not $I), it's truncated, or the header version isn't 1 or 2. The parser reports the exact reason it rejected the file.

How to parse $I Recycle Bin files (no install)

A $I is small enough that any of three approaches will get you a clean read. The choice is about workflow, not capability.

Approach	Install required	Best for
Browser parser	None	One-off analysis, sensitive files (no upload), demos
RBCmd	.NET runtime	Batch CSV output on a Windows DFIR workstation
Manual hex walk	Hex editor	Verifying a tool, learning the format, carving fragments

RBCmd — what most DFIR shops actually run

Eric Zimmerman's RBCmd is the de-facto standard. On a Windows analysis workstation:

RBCmd.exe -d "C:\$Recycle.Bin" --csv . --csvf recyclebin.csv

-d recurses through every user-SID subfolder. The output drops straight into Timeline Explorer or Excel. Add --mp to also process $R files and surface mismatches between recorded size and actual $R size — a fast tamper check.

For a whole image, point -d at the mounted volume root. RBCmd handles $I* files across every SID subfolder in one pass.

In-browser parser

Drop one or many $I files onto the page. Each row shows the original file name, the full original path, original size in bytes, the deletion FILETIME rendered in your locale, and the detected format version. CSV export uses strict ISO-8601 UTC so it slots into existing Timeline Explorer pipelines.

Everything runs locally via WebAssembly — useful when the source $I contains paths that themselves leak case-sensitive information and you do not want to ship them to a third party.

Reading it by hand

Eight-byte version, eight-byte size, eight-byte FILETIME, then path. That is it. See the $I file format post for the v1/v2 differences in the path encoding.

A v1 $I is exactly 544 bytes. A v2 $I is variable; its path length sits at offset 0x18 as a uint32. If a tool accepts a v1 $I that is not 544 bytes, distrust it.

Common parse failures

It is actually a $R, not a $I. Easy to do when filtering by prefix sloppily.
Truncated v1. Often 16 bytes (just the header). Carvers occasionally produce these.
Version byte not 1 or 2. Garbage from carving. Sanity-check the upper seven bytes of the version field — they must be zero.
Path length lies. A v2 $I whose path length implies a file larger than the on-disk size. Tooling that does not bounds-check will read past the end of the buffer.

Cross-corroboration

Pair $I entries with the MFT for $STANDARD_INFORMATION timestamps on the original path, and the USN journal for the matching RENAME_OLD_NAME / FILE_DELETE records. Three artefacts agreeing on a deletion sequence is a defensible finding.