# hx: a Rust hexdump with colour, octal, binary and source array output

> hx is a Rust rewrite of the classic hexdump that prints a colourised hexadecimal view of a file or standard input, and adds formats the original never had: octal, binary, and the file bytes emitted as source code arrays in eight languages. It installs from crates.io, from distro packages or as a Docker image.

**sitkevij/hex** — 🔮 Futuristic take on hexdump, made in Rust. 

- Repository: https://github.com/sitkevij/hex
- Stars: 569 · Forks: 35
- Language: Rust
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/sitkevij-hex

## One binary, three names

The naming is the first thing to sort out. The repository is called hex, the project is called hex in the README title, the binary is hx, and the crate on crates.io is hx, as the badges show with the crates.io badge pointing at crates.io/crates/hx. The man page is hx.1 and the install instructions all produce a command called hx. The description is a futuristic take on hexdump, made in Rust, and the tool itself accepts a file path or stdin as input and outputs a hexadecimal colorized view to stdout. The effect of the rename is that a user typing hx gets the modern tool, while the name hex still belongs to a different project in most people's muscle memory. The primary language is Rust, the licence is MIT, and the repository topics list ascii, binary-data, bytes, developer-tools, hex, hexadecimal, hexdump, rust and xxd, which places it clearly in the same family as xxd.

## What the default output looks like

The README shows the default format against a test file, and the example is worth reading because the layout is the tool's identity. Running hx on a file path gives sixteen bytes per line with the offset in hexadecimal at the start, the bytes themselves in the middle, and the ASCII rendering at the end:

```sh
$ hx tests/files/alphanumeric.txt
0x000000: 0x61 0x62 0x63 0x64 0x65 0x66 0x67 0x68 0x69 0x6a abcdefghij
0x00000a: 0x6b 0x69 0x6c 0x6d 0x6e 0x6f 0x70 0x71 0x72 0x73 kilmnopqrs
```

The line ends with a total byte count, and the ASCII column shows a dot or a space for anything outside the printable range, which is the convention every hexdump shares. The stdin path produces identical output, and the README demonstrates it with a pipe:

```sh
cat tests/files/alphanumeric.txt | hx
0x000000: 0x61 0x62 0x63 0x64 0x65 0x66 0x67 0x68 0x69 0x6a abcdefghij
0x00000a: 0x6b 0x69 0x6c 0x6d 0x6e 0x6f 0x70 0x71 0x72 0x73 kilmnopqrs
```

The two examples in the README are the same file, and they are byte-identical, which is the point: whether the data arrives as an argument or on standard input, the tool does the same thing.

## Octal and binary views, and what the format flag actually takes

The options block in the README is the complete specification of the tool, and it is short. The -f, --format option sets the format of the octet, with the possible values Octal (o), LowerHex (x), UpperHex (X) and Binary (b). The -c, --cols option sets the column length, the -l, --len option sets how many bytes to read, and -t, --color sets a colour tint for the terminal output with 0 to disable and 1 to enable. The -u, --func option sets the function wave length and -p, --places sets the decimal places in the function wave output, both of which relate to a graph-style rendering of the bytes rather than to plain listing. The README illustrates the two non-hex formats with screenshots rather than text, using the command hx -fb -c4 for the binary format and hx -fo -c8 for octal, so the -c flag doubles as the column width control that makes a binary view readable at all, since each byte takes far more room in binary than in hex.

## Turning a file into a source code array in eight languages

The feature that distinguishes hx from every other hexdump is the -a, --array option, which outputs the input file bytes as source code arrays. The README gives a separate example for each supported language, and the language set is the option's possible values: rust (r), C (c), golang (g), python (p), kotlin (k), java (j), swift (s) and fsharp (f). The Rust form looks like this:

```sh
$ hx -ar -c8 tests/files/tiny.txt
let ARRAY: [u8; 3] = [
    0x69, 0x6c, 0x0a
];
```

and the C form is:

```sh
$ hx -ac -c8 tests/files/tiny.txt
unsigned char ARRAY[3] = {
    0x69, 0x6c, 0x0a
};
```

The remaining six follow the same pattern with the syntax of each language, including the F# form with its byte literals and the Python form as a plain list. This is a small idea with a large reach. Pasting a binary blob into a test fixture or a protocol implementation is a chore that hexdumps exist to make tedious, and emitting the literal in the target language removes the transcription step entirely, which is where transcription bugs come from.

## Installing it, five different ways

hx is packaged and available for install on the platforms tracked by Repology, and the README gives the routes. From crates.io, if cargo is already installed, the install is:

```sh
cargo install hx
```

From a source checkout, make install runs the cargo commands that build the release version, run the tests and install the binary to the cargo bin directory:

```sh
make install
```

The README notes that this will compile the release version, run tests and install the release binary to the user directory's .cargo/bin/hx, so if that directory is on your PATH the command works anywhere in the shell. There are distribution-specific routes too. On Arch Linux it is pacman -S hex, on Debian the README shows a curl and dpkg sequence against a versioned release artefact, and on Guix it is guix install hex, with guix shell --container hex for an isolated environment. The Docker route treats hx as a filter, which is the natural shape for a tool that reads standard input:

```sh
# stdin
cat README.md | docker run -ti sitkevij/hx:latest
```

The Dockerfile in the repository is a two-stage build, with a rust:latest builder stage that runs cargo install --path ., and a debian:bookworm-slim runtime that copies only the hx binary across, so the final image carries no Rust toolchain.

## The colour question, and the NO_COLOR convention

Because hx colours its output by default, the tool has to deal with the fact that coloured output is wrong in some contexts, chiefly when the output is piped into something that reads the bytes rather than the colours. hx honours the NO_COLOR environment variable, and if it is set, no colour is output to the terminal. The README links the no_color crate on crates.io and a fork of it on GitHub, and the manifest pins that crate as a dependency, so the behaviour is a first-class feature rather than a heuristic. The Docker example shows how it is used in practice, since the environment variable has to be passed into the container for the setting to take effect there:

```sh
# file input with parameters and NO_COLOR environment variable
echo "NO_COLOR=1" >docker_env_vars.ignore.txt &&
docker run -ti --env-file docker_env_vars.ignore.txt -v $(pwd)/README.md:/README.md sitkevij/hx:latest -fo -c8 /README.md
```

The -t and --color option with 0 to disable and 1 to enable is the in-tool alternative for the same need, so a user can turn colour off without exporting anything.

## Where hx is the wrong tool

Three limits are worth naming. The first is scope. A traditional hexdump such as xxd or the original hexdump has options for switching between layouts, comparing two files and producing plain output for a machine to read, and hx's option list has none of those, so if your workflow depends on diffing two binaries with a hex dumper, hx will not do it. The second is the size of the language array feature relative to the rest of the tool. The array output is a convenience for pasting bytes into code, and it is a strong one, but it is the only substantial addition over a hexdump, and the tool does not attempt to be a general binary file inspector with structure awareness. The third is the distribution model. The crate is published as hx on crates.io, the Arch package is named hex and the Guix package is also hex, so a user searching for hex on those systems may find a different tool, and the naming mismatch between the repository name and the binary name is a genuine papercut in a tool people invoke by name. On maintenance, the newest release is v0.7.1 on 2026-10-12 with the last push the same day, and the previous releases were v0.7.0 on 2025-12-01 and v0.6.0 on 2024-01-02, so the pace has picked up after a quiet year.

## Conclusion

hx suits a developer who reads binary regularly and wants a hexdump that is faster to scan than the original, and it earns its place for the formats it adds rather than for the hex itself, since octal, binary and the language array output have no equivalent in the classic tool. It is the wrong tool if you need the switch, plain, or diff features of a traditional hexdump, and it is the wrong tool if your workflow depends on a specific format the tool does not implement. Verify first that the output format you want exists, since the option list is fixed at eight array languages and four octet formats, and note that the crate is published as hx rather than hex, the man page is hx.1, and the newest release is v0.7.1 from 2026-10-12.

## FAQ

### How do I install hx, the Rust hexdump?

From crates.io with cargo install hx, from a source checkout with make install, from a distro package such as pacman -S hex on Arch or guix install hex on Guix, or as a Docker image with sitkevij/hx:latest.

### What output formats does hx support?

The -f, --format option sets the octet format with the possible values Octal (o), LowerHex (x), UpperHex (X) and Binary (b). There is also a -a, --array option that emits the bytes as a source code array in rust, C, golang, python, kotlin, java, swift or fsharp.

### How do I turn off the colour output of hx?

Set the NO_COLOR environment variable and hx will output no colour to the terminal, which the README links to the no_color crate for. There is also a -t, --color option where 0 disables and 1 enables the colour tint.

### Can hx read from standard input?

Yes. The usage line in the README shows hx [OPTIONS] [INPUTFILE] with a separate form of <stdout> | hx [OPTIONS], and the example pipes a test file through cat into hx with output identical to the file argument form.

### Why is the tool called hx when the repository is called hex?

The binary, the crates.io package and the man page are all hx, with the crate published as hx on crates.io, while the repository itself is named hex. The distribution package names also differ, with hex used on Arch Linux and Guix.

## Sources

- [Issues](https://github.com/sitkevij/hex/issues)
- [License: MIT](https://github.com/sitkevij/hex/blob/master/LICENSE)
- [README](https://github.com/sitkevij/hex/blob/master/README.md)
- [Releases](https://github.com/sitkevij/hex/releases)
- [sitkevij/hex on GitHub](https://github.com/sitkevij/hex)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sitkevij-hex