rom-properties reads the ROM header and shows it inside your file manager

A tab that reads the image, not the filename

rom-properties is a shell extension, in the sense that it plugs into the file browser itself and adds a tab called ROM Properties. The project description calls it a shell extension for managing video game ROM and disc images, and the feature table confirms the shape of the thing: a properties tab, an XAttrs tab, thumbnails, a dangerous overlay, metadata, columns and a context menu entry.

The mechanism is worth stating plainly. Rather than matching a filename against a list, the extension reads the image file and parses the headers that console formats put at known offsets. The v2.9 notes name two of those parsers directly, a Game Maker Studio data.win parser and a PlayStation PARAM.SFO parser. The repository topic tags cover systems such as the Nintendo DS, 3DS, Game Boy, NES, SNES, Mega Drive, Nintendo 64, Dreamcast, Wii and Wii U, plus PlayStation and Xbox images, which is the range of formats the parsers target.

For the user, the effect is that the file browser becomes the front end for a collection. Right-clicking a file, opening Properties and clicking the ROM Properties tab is said to show more information about the ROM image, and for supported formats a thumbnail is generated so the browser shows cover art in grid view. The extension also reaches beyond the tab. On Windows the icon or banner shown on the ROM Properties tab can be dragged into a folder to extract it as a PNG, and a context menu entry converts supported texture formats to PNG. That extraction path matters for anyone who wants the artwork as a separate file rather than as a preview.

Six shells, and the plugin API behind each one

The supported list is long because every file browser exposes a different extension API, and rom-properties ships a separate implementation for each. The documented set is KDE Frameworks 5.x and 6.x with Dolphin and Konqueror, XFCE with Thunar, GNOME 3.x through 42 with Nautilus, GNOME 43 with Nautilus, MATE Desktop 1.18 and later with Caja, Cinnamon with Nemo, and Windows 7 or later.

A second tier is listed as still compatible but likely to receive less support: KDE 4.x, and Windows XP SP3, Windows Server 2003 SP2 and Windows Vista. The caveat for those older Windows versions is concrete rather than vague. WinInet in older Windows releases does not support the newer encryption algorithms used by the online database hosts, so working around it requires downloading an older version of cURL together with a certificate bundle, and the project points to the Releases page for both.

Below the visible feature list there is a second dimension that matters more than the version numbers: what each shell can technically carry. The metadata that rom-properties extracts, such as the title and the cover art, has to travel through the desktop's own metadata store to reach the file browser, and those stores differ in capability. Where a shell has no interface for extended attributes or custom columns, the extension cannot offer overlays or a column view no matter how well the parser works. The rest of this article leans on that distinction, because it decides what a given user will actually see after installation.

Installing on Linux and switching on the Dolphin preview

The Linux instructions are short because most of the work is done by packaging. You install the relevant .deb package, choosing the one that matches your desktop environment and your CPU, and then the plugin has to be enabled inside the file browser. For Dolphin the documented sequence is to close every running instance of the browser, start it again, open Control and then Configure Dolphin, click the General section and then the Preview tab, tick the ROM Properties Page item and confirm with OK, and finally enable previews in a directory that holds a supported file type.

If that worked, thumbnails appear for the supported file types, and the properties route still works by right-clicking a file, selecting Properties and clicking the ROM Properties tab.

Two things about this flow are easy to miss. First, the preview toggle is a per-directory setting in the Dolphin interface, so enabling it once does not cover every folder where your library lives. Second, the plugin has to be listed and ticked before Dolphin will show anything, so a user who installs the package and expects the tab immediately will conclude the install failed. There is no command line in the documentation for enabling the preview, so this part is a manual step in the browser rather than something that can be scripted.

The project also documents building from source separately, with a pointer to doc/COMPILING.md for the actual instructions. The repository layout supports that route, with a CMakeLists.txt at the top level, a cmake directory, src and extlib directories, a debian directory for packaging and separate xdg directory. Because those instructions live in a separate document rather than the README, anyone compiling from source should read that file rather than guess at the steps.

Windows still means an installer and a runtime package

The Windows path is different in two ways that matter for a decision. First, only a system-wide installation is supported, so running the installer requires administrator access. Second, the Visual C++ runtime has to match both the Windows version and the CPU architecture, and the README splits that into three sets of downloads.

On Windows 10 and later, the MSVC 2015-2026 runtime is needed, with separate links for i386, amd64, arm32 and arm64. On Windows Vista, Windows 7 and Windows 8.x, the older MSVC 2015-2022 runtime applies, with links for i386, amd64 and arm32. On Windows XP and 2003 and earlier, the MSVC 2015-2017 runtime is the one, again with i386 and amd64 links. The arm32 links point at rpdb.gerbilsoft.com while the others point at Microsoft download endpoints, which is a small inconsistency worth checking when an ARM machine is the target.

The older Windows support is real rather than nominal, since a dedicated release exists for it, but it carries the WinInet limitation described earlier, where the online database hosts need newer encryption algorithms than those systems provide. In practice that means the metadata and thumbnail features that reach out to those hosts degrade on Windows XP and Vista unless the older cURL and a certificate bundle are installed as well.

Windows also carries the one asymmetry that no other platform has: the dangerous overlay is not implemented there, even though the rest of the feature set is marked as supported across the modern Windows versions.

The feature matrix is where the real limitations sit

The README states support for a shell extension in terms of its own features, and reading the matrix across is more useful than reading the platform list. Properties tab, XAttrs tab, metadata and the context menu are marked as supported on Windows XP, on Windows Vista through 11, on KDE, on GNOME and on XFCE. Thumbnails are supported everywhere, with a footnote for GNOME. The dangerous overlay is unsupported on Windows XP and on Windows Vista through 11, supported on KDE and GNOME, and blocked on XFCE. Columns are supported on the Windows columns and on GNOME, but blocked on KDE and on XFCE.

Each of those four footnotes names a specific cause rather than a preference. GNOME sandboxes the thumbnailing software it runs, which may prevent rom-properties from downloading images from the online databases, so a GNOME user can end up with locally parsed metadata but no cover art. ThunarX has no interfaces for adding custom file attributes such as overlays and metadata, or for displaying custom columns, so the XFCE gap is a property of that plugin infrastructure. KDE has a fixed set of metadata properties with no mechanism to extend it outside of updates to KFileMetaData, which is why the columns row is marked as unsupported there even though the properties tab works.

This is the practical trap in adopting the project. The parsers are the same everywhere, but what a user can see depends on the desktop's metadata stack. That also explains why the overlay row differs between Windows and Linux: on Windows the equivalent feature is simply not implemented, rather than being blocked by the shell.

v2.9 adds parsers, a CPU report and PNG extraction

The v2.9 notes describe the most recent feature work and give a fair picture of what is still changing. Two parsers were contributed, one for Game Maker Studio data.win files and one for PlayStation PARAM.SFO. The command line tool rpcli gained a -P option that lists the CPU features detected on the current system, currently supporting x86 and ARM. On Windows, the icon and banner from the ROM Properties tab can be dragged and dropped into a folder window to extract it in PNG format. Games for Windows Live and XNA executables now show an Xbox 360-style XDBF tab for Achievements. KDE Frameworks 6 now uses the system-wide file size unit dialect setting instead of assuming IEC-style units such as KiB and MiB.

The release also added Georgian translations and, in the project's own words, a lot of tiny bug fixes and improvements. Translations are handled through Crowdin, and the README asks for new translators both through that project and, for languages not listed there, through a GitHub issue.

Two supporting documents are named for detail. NEWS.md holds the full list of changes for v2.9, and NETWORK.md sits alongside it at the top level of the repository. The release cadence is visible in the tag history: v2.9 on 2026-09-13, v2.8 on 2026-06-20 and v2.7.1-xp64 on 2026-04-26, a tag built specifically for Windows XP. That last tag is a good signal about how the older platform is treated, as a separate maintained line rather than a footnote. The last push to the repository was on 2026-10-20, so work continues between tagged releases as well.

Parsing headers locally against looking images up online

rom-properties takes a different approach from the obvious alternative, which is to identify an image by its name or by a checksum against a database. Here the metadata comes from parsing the image itself, so the title, region, format and cover art are read out of the file that already sits on your disk. That approach needs no account, no key and no round trip to a service, and it works offline for everything that lives in the header.

The catch is visible in the documentation. Some of what the extension shows is not in the header at all. Thumbnails for GNOME are fetched by downloading images from online databases, which is exactly what the sandboxing footnote blocks, and the older Windows limitation is about the encryption algorithms those same online database hosts require. So the project has two paths side by side: local parsing for metadata, and a network lookup for artwork and any other hosted data. A user on a restricted network gets a partially populated tab, and the README does not document a switch that would disable the online lookup and keep only the local results.

For anyone who wants to verify or repair a dump rather than browse a collection, that is the wrong shape of tool. rom-properties presents what it reads and offers to extract the artwork, but the project does not describe checksum verification or redump tooling as part of what it does.

Editorial conclusion

rom-properties fits a collector with a large library of ROM and disc images who wants metadata and cover art without opening an emulator, and it works best on KDE and GNOME where the properties tab, overlays and thumbnails are all supported. It is the wrong choice if you need to verify a dump against a trusted hash, since the project does not describe that as one of its features, or if your only shell is XFCE, where custom file attributes and columns are unavailable by design of the plugin infrastructure. Before installing, check the feature table in the README against the file browser you actually use, then read doc/COMPILING.md if you intend to build from source, and note that the last push was on 2026-10-20.

Frequently asked questions

Official sources

1. GerbilSoft/rom-properties on GitHub
2. Issues
3. License: GPL-2.0
4. README
5. Releases