ImHex-Patterns: A Community Database of Binary Format Definitions

A Content Database Rather Than an Application

ImHex-Patterns is a repository of files to use with the ImHex hex editor, and it is structured as a database rather than as a program. There is no build step to run and no library to install in order to use it in the editor, because the editor fetches the content.

The nine kinds of artefact it holds are listed in the README, and they are the whole inventory:

patterns/
includes/
magic/
encodings/
nodes/
themes/
constants/
scripts/
yara/

The top level of the repository adds more, with disassemblers/, plugins/ and tips/ directories alongside the ones above, plus tests/, a CMakeLists.txt, a.gitmodules file and a CONTRIBUTING.md.

So the repository is a little more than the nine listed categories once the tree is read fully, and that is worth knowing if you are looking for where a particular kind of file should go.

The relationship to the editor is the important part. The homepage points at the ImHex repository itself, because this is where ImHex's data lives, and the README says that everything in it immediately shows up in ImHex's Content Store and gets bundled with the next release of ImHex. The database and the editor are versioned separately, and the database ships with the editor.

Nine Artefacts, Nine Different Purposes

Each directory answers a different question about the bytes, and mixing them up is the most likely reason a contribution does not land where you expect.

Patterns are binary format definitions for the Pattern Language, and they are the bulk of the repository. Pattern libraries, in the includes directory, are libraries that make using the Pattern Language easier, which in practice means reusable definitions a pattern can include rather than redefining from scratch.

Magic files are custom magic file definitions for use with libmagic, which is the same file type identification mechanism the Unix file command uses, and having a custom one means ImHex can identify a format the system cannot.

Encodings are custom encodings in the.tbl format, which is the mapping from a byte sequence to characters. Data Processor nodes are custom nodes made for ImHex's Data Processor.

Themes are custom themes for the editor, constants are constant definition files, scripts are various scripts to generate code or automate some tasks, and Yara holds custom Yara rules, which is a pattern matching language for malware analysis that is a different thing from an ImHex pattern even though both describe byte structures.

What a Pattern Actually Describes

The table of contents in the README is the most useful part of the repository, because it shows the range of formats covered and, more importantly, the level of detail the maintainers expect.

Each row has a name, a MIME type where one applies, the path to the pattern file, and a description. The rows show the spread: a Windows Recycling Bin $I file at patterns/ifile.hexpat, an Autodesk 3DS Max model file, a 7z file format, an ADTFDAT file, ADTS and AAC audio files with the audio/x-hx-aac-adts MIME type, a Nintendo Switch Atmosphère CFW fatal error log, AMD Linux kernel microcode containers and patches, a Windows animated cursor file, the Apple File System at patterns/fs/apfs.hexpat, AppleSingle and AppleDouble resource forks, a static library archive, Minecraft legacy console edition ARC files, an ARM Cortex-M vector table layout, and a long run of game engine formats including Arma 3 configs, P3D models, PAA textures, RTM animations and texture headers.

Two things stand out in that list. The first is that the MIME column is filled in for some formats and empty for others, which tells you the maintainers treat a MIME type as a useful piece of metadata rather than a requirement. The second is the paths, where some formats live in their own directory with several files, such as the Arma 3 set under patterns/a3/, while most are a single .hexpat at the top of patterns/.

Magic Files, Yara Rules and the Other Overlaps

Several of the artefact types describe the same file format in different ways, and it is worth being clear about which to use when.

A pattern tells ImHex how to decode a structure. A magic file tells the system what a file is, using the libmagic format that the file command on Unix uses. A Yara rule matches byte sequences with a different language entirely, one designed for scanning collections of files for indicators rather than for interactive decoding.

The magic directory therefore duplicates a small amount of ground with the patterns, on purpose, because the two answer different questions: one identifies a file, the other explains it.

The encodings directory is a third case, since an encoding maps bytes to text, which matters for the formats that carry strings in a non-obvious code page.

The constants directory is the least obvious of the set and the most reusable, because a constant definition is a named value that several patterns can refer to, which is how a format family with a shared header or a version field avoids every pattern redefining it.

The Content Store and the Release Cadence

The distribution mechanism is the part that makes this repository different from a folder of example files, and it is stated in one sentence: most files in this repository have been submitted by the community, please feel free to open a PR on your own and add files to it, and everything will immediately show up in ImHex's Content Store and gets bundled with the next release of ImHex.

So there are two stages. A merged pull request appears in the Content Store right away, which means a user who has the content store enabled gets the new pattern without waiting for an editor release. And the file is also bundled with the next ImHex release, which means it ships inside the editor for people who do not use the content store.

The release history is the editor's rather than the database's, with ImHex-v1.38.1 from 2025-12-21, ImHex-v1.38.0 from 2025-12-06 and ImHex-v1.37.4 from 2025-02-26. So the editor ships several times a year, and each of those releases is when a batch of the contributed patterns becomes part of the default install.

That is the practical planning point for a project that depends on a format definition. A pattern you add is available through the content store immediately, but a user on an older editor will not have it unless they update, so the version of the editor in the field is worth tracking.

The last push to the repository was on 2026-09-22, which is later than the newest listed editor release, so the database is ahead of the bundled set.

Adding a Pattern and the Conventions to Follow

The contribution path is a pull request with a file in the right directory, and the README invites that directly.

The convention that a contributor can infer from the table of contents is that a pattern is a .hexpat file named after the format, placed in patterns/, with a directory created when a format needs several files. The description goes in the table row, and the MIME type is added when one applies. Where a format is documented elsewhere, the description links out, as the ADTFDAT and Bink rows do, and where the pattern came from a third party repository, the table points at that repository instead, as the Bastion row does.

The Bastion case is instructive, because it shows the two acceptable ways to contribute a pattern set that is large. Either the files are copied into the repository, as the Arma 3 patterns are, or the table links to an external repository that ImHex pulls from, as the Bastion row does. Both are in the table, so both are understood.

The CONTRIBUTING.md file is pointed at for detailed guidelines, and the repository has a tests/ directory and a CMakeLists.txt, which suggests the content is validated in some automated way before it reaches the store, although the README does not describe how the validation works.

Editorial conclusion

ImHex-Patterns fits a reverse engineer who uses ImHex and wants a format definition for a file the editor does not already know, and it fits a tool author who needs the same definitions in a machine readable form. It is a poor fit if you are not using ImHex, since the patterns are written in ImHex's own pattern language, and it is a poor fit if you need a stable, versioned API, because the content is a rolling database that changes with every merged pull request. Before contributing, read CONTRIBUTING.md and look at an existing pattern for the conventions, and note that a merged pattern is not released immediately but is bundled with the next ImHex release, so plan your rollout around that cadence. The repository is GPL-2.0 licensed, and the last push was on 2026-09-22.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. WerWolv/ImHex-Patterns on GitHub