When you are handed an unknown binary — a firmware image, a cache file, a custom save format — three quick measurements tell you a lot before you ever open a hex editor: what readable text it contains, how its bytes are distributed, and how random each region is. This inspector computes all three in your browser so you can characterize a file at a glance.
How it works
The tool reads the file into a byte array and runs three analyses:
- String extraction finds runs of printable ASCII (
0x20–0x7e) of at least four characters, the same approach as the Unixstringscommand. This surfaces embedded URLs, file paths, error messages and metadata. - Byte-frequency histogram counts how often each of the 256 possible byte values appears. Text files spike around the ASCII range; compressed or encrypted files look nearly flat.
- Shannon entropy is computed both overall and per fixed-size block. Entropy
H = -Σ p·log2(p)ranges from 0 bits per byte (a single repeated value) to 8 bits per byte (uniformly random). The per-block values are drawn as a heatmap from green (ordered) to red (random).
How to read the results
A low overall entropy (under ~4.5) usually means text, source code or sparse structured data. Values around 6–7 point to media or compressed content, and anything above ~7.5 is the signature of encryption, compression, or packed data. The heatmap adds spatial detail: a common pattern is a low-entropy header or table near the start, followed by a solid red block where the compressed or encrypted payload lives. Combine that with the extracted strings — a magic word, a library version, a copyright notice — to identify the format. All of this runs locally, so even confidential files never leave your device.
Typical patterns you will see
| File type | Overall entropy | Byte histogram shape | Heatmap |
|---|---|---|---|
| Plain text / source code | 3.5 – 5.5 | Spikes around ASCII printable range (0x20–0x7E) | Mostly green |
| Executable (ELF, PE) | 5.0 – 6.5 | Mixed: ASCII spike + code byte spread | Green header, mid-entropy code section, red if packed |
| ZIP / gzip compressed | 7.2 – 7.9 | Nearly flat across all 256 values | Solid red |
| AES-encrypted payload | 7.9 – 8.0 | Flat — almost perfectly uniform | Solid red with no variation |
| JPEG image | 6.5 – 7.5 | Relatively flat with slight bias toward low values | Medium to high red |
| SQLite database | 3.0 – 5.0 | Sparse — many 0x00 bytes, some text range | Alternating green and mid blocks |
Useful string extraction patterns
The strings view is where many quick identifications happen. Useful strings to look for:
- Magic bytes as text —
MZat offset 0 means a Windows executable;ELFmeans a Linux binary;PKmeans a ZIP-based archive (including DOCX, XLSX, JAR). - Library or product names — embedded version strings like
OpenSSL 1.1.1torzlib 1.2.11identify dependencies. - File paths and build artifacts — strings like
/home/user/build/project/main.creveal the build environment and can help attribute a file. - Error messages — hard-coded error strings from a program’s source code are distinctive identifiers even when no other readable metadata survives.
- URLs and IP addresses — indicate where the binary phones home or fetches resources from, relevant for malware triage.
The 16 MB limit keeps analysis responsive. For larger firmware or disk images, extract a representative region (for example the first 16 MB or a known payload section) and inspect that slice.