About

Every file on disk is a sequence of bytes. A binary dump renders those bytes in human-readable columns so you can inspect headers, locate magic numbers, and verify data integrity at the byte level. Misidentifying a file's internal structure leads to corrupted parsers, failed forensic analysis, and silent data loss. This tool reads any file entirely client-side using the File API and ArrayBuffer, then maps each byte to its binary (01101001), hexadecimal (0x69), octal (151), or decimal (105) representation. An ASCII sidebar decodes printable characters in the range 0x20 - 0x7E; non-printable bytes display as ·. Virtual scrolling keeps the interface responsive for files up to 100 MB. No data leaves your browser.

The tool approximates a desktop hex editor experience within browser constraints. Files larger than 100 MB may cause memory pressure on devices with limited RAM. For forensic work, cross-reference magic bytes against the reference table below to identify file types without relying on extensions. Pro tip: JPEG files always start with FF D8 FF; if yours doesn't, the file is truncated or misnamed.

Formulas

Each byte b in the file's Uint8Array is an unsigned integer in the range [0, 255]. The conversion to each display base follows:

hex = b.toString(16).padStart(2, "0")

bin = b.toString(2).padStart(8, "0")

oct = b.toString(8).padStart(3, "0")

The ASCII sidebar maps byte b to a printable character using:

char =

{

String.fromCharCode(b) if 0x20 ≤ b ≤ 0x7E· otherwise

The file offset for row r with n bytes per row is:

offset = r × n

Where r = row index (zero-based), n = bytes per row (8 or 16), b = a single unsigned byte value, offset = byte position from file start displayed in the gutter.

Reference Data

File Type	Extension	Magic Bytes (Hex)	Offset	Description
JPEG Image	.jpg / .jpeg	FF D8 FF	0	JFIF/EXIF image start-of-image marker
PNG Image	.png	89 50 4E 47 0D 0A 1A 0A	0	8-byte PNG signature with DOS/Unix line ending test
GIF Image	.gif	47 49 46 38	0	GIF87a or GIF89a header
PDF Document	.pdf	25 50 44 46 2D	0	ASCII: %PDF- version header
ZIP Archive	.zip	50 4B 03 04	0	Local file header signature (PK\x03\x04)
RAR Archive	.rar	52 61 72 21 1A 07	0	RAR5 or RAR4 archive marker (Rar!)
7-Zip Archive	.7z	37 7A BC AF 27 1C	0	7z signature bytes
ELF Executable	(none)	7F 45 4C 46	0	Unix/Linux executable & linkable format
PE Executable	.exe / .dll	4D 5A	0	DOS MZ header (Mark Zbikowski signature)
Mach-O (32-bit)	(none)	FE ED FA CE	0	macOS/iOS 32-bit executable
Mach-O (64-bit)	(none)	FE ED FA CF	0	macOS/iOS 64-bit executable
WAV Audio	.wav	52 49 46 46 .. .. .. .. 57 41 56 45	0	RIFF header with WAVE sub-type at offset 8
MP3 Audio	.mp3	FF FB or 49 44 33	0	MPEG frame sync or ID3v2 tag header
OGG Container	.ogg	4F 67 67 53	0	OggS capture pattern
FLAC Audio	.flac	66 4C 61 43	0	fLaC stream marker
MP4 / MOV Video	.mp4 / .mov	.. .. .. .. 66 74 79 70	4	ISO Base Media ftyp box at offset 4
WebM Video	.webm	1A 45 DF A3	0	EBML header (Matroska/WebM container)
SQLite Database	.db / .sqlite	53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00	0	ASCII: "SQLite format 3\0"
GZIP Compressed	.gz	1F 8B	0	GZIP magic number with compression method
BMP Image	.bmp	42 4D	0	BM bitmap file header
TIFF Image (LE)	.tiff	49 49 2A 00	0	Little-endian TIFF (II + version 42)
TIFF Image (BE)	.tiff	4D 4D 00 2A	0	Big-endian TIFF (MM + version 42)
WebP Image	.webp	52 49 46 46 .. .. .. .. 57 45 42 50	0	RIFF header with WEBP sub-type at offset 8
WASM Binary	.wasm	00 61 73 6D	0	WebAssembly binary magic (\0asm)
Java Class	.class	CA FE BA BE	0	Java compiled bytecode identifier

Frequently Asked Questions

The entire file is read into a single ArrayBuffer in memory, but the DOM only renders the rows visible in the viewport plus a small overscan buffer (typically 10 rows above and below). As you scroll, the tool calculates which byte range maps to the visible area using the formula offset = scrollTop / rowHeight × bytesPerRow, then regenerates only those ~60-80 rows. This keeps DOM node count constant regardless of file size. Files up to 100 MB work reliably on devices with at least 512 MB of free browser memory.

The ASCII column only renders printable characters in the range 0x20 (space) through 0x7E (tilde). Bytes outside this range - including control characters (0x00-0x1F), DEL (0x7F), and extended bytes (0x80-0xFF) - are non-printable and would render as invisible or garbled glyphs. The middle dot (·) serves as a uniform placeholder that preserves column alignment while clearly indicating non-printable data.

Most file formats embed a magic number - a fixed byte sequence - at a known offset, typically byte 0. For example, PNG files always begin with the 8-byte sequence 89 50 4E 47 0D 0A 1A 0A. JPEG starts with FF D8 FF. ZIP archives use 50 4B 03 04. Consult the reference table above and compare the first 4-16 bytes of your dump. Some formats like MP4 place the magic bytes (ftyp) at offset 4 rather than 0, so check the offset column.

Endianness determines the order in which bytes of a multi-byte value are stored. In little-endian (used by x86/ARM), the least significant byte comes first: the 32-bit integer 0x01020304 is stored as 04 03 02 01. In big-endian (network byte order, used by many file formats), it is stored as 01 02 03 04. When inspecting multi-byte fields such as integer sizes in file headers, selecting the wrong endianness yields incorrect values. TIFF files, for instance, declare their endianness in the first two bytes: 49 49 for little-endian, 4D 4D for big-endian.

Yes. The search field accepts both ASCII text (e.g., "PNG") and hex byte sequences (e.g., "FF D8 FF E0"). For text input, each character is converted to its byte value using charCodeAt. For hex input, the string is split by spaces and each pair is parsed with parseInt(pair, 16). The tool then performs a linear scan (Boyer-Moore-Horspool optimized) across the Uint8Array and scrolls to the first match, highlighting the matching bytes. On large files, the search runs in a Web Worker to avoid blocking the UI.

No. The File API's FileReader.readAsArrayBuffer creates a read-only copy of the file's bytes in browser memory. The original file on disk is never written to, locked, or modified. All operations - display, search, copy - operate on this in-memory copy. When you load a new file or close the tab, the ArrayBuffer is garbage-collected.