User Rating 0.0 ★★★★★

Total Usage 0 times

Category Code Utilities

Drop any file here or click to browse Supports all file types · Processed locally

Is this tool helpful?

Your feedback helps us improve.

★ ★ ★ ★ ★

About

Every file on disk is a sequence of bytes. Text editors hide this reality behind character encodings. When you need to verify a file signature, inspect a corrupted header, or reverse-engineer a binary protocol, you need raw byte access. This tool renders any file as a paginated hex dump with synchronized ASCII preview, byte-level selection, and multi-type value inspection via DataView. It operates entirely in-browser using the File API and ArrayBuffer - no data leaves your machine. Limitation: rendering is paginated at 256 bytes per page to keep DOM size constant regardless of file size. Files of any size load, but navigation is page-based, not scroll-based.

Common use cases include verifying magic bytes (e.g., PNG files start with 89 50 4E 47), locating embedded strings in firmware images, and debugging serialization formats. The inspector panel decodes the selected byte's offset and value as signed/unsigned integers, IEEE 754 floats, and both big-endian and little-endian representations. Pro tip: file format specifications almost always document offsets in hexadecimal - use the offset column on the left to cross-reference directly.

Formulas

Byte-to-hexadecimal conversion maps each 8-bit value to a two-character string in base 16:

hexString = byte.toString(16).padStart(2, "0")

The file offset for any byte on page p at position i within that page is:

offset = p × PAGE_SIZE + i

where PAGE_SIZE = 256 bytes by default. ASCII printable range check determines character display:

{

char(b) if 0x20 ≤ b ≤ 0x7E"." otherwise

Multi-byte value interpretation uses DataView with explicit endianness. For a 16-bit unsigned integer at offset o:

value_LE = byte[o] + byte[o+1] × 256

value_BE = byte[o] × 256 + byte[o+1]

where o = absolute byte offset in the file. IEEE 754 single-precision float uses 4 consecutive bytes; double-precision uses 8.

Reference Data

File Type	Extension	Magic Bytes (Hex)	Offset	Description
PNG Image	.png	89 50 4E 47 0D 0A 1A 0A	0x00	PNG signature with DOS/Unix line ending checks
JPEG Image	.jpg	FF D8 FF	0x00	JFIF/EXIF marker start
GIF Image	.gif	47 49 46 38	0x00	GIF87a or GIF89a
PDF Document	.pdf	25 50 44 46 2D	0x00	%PDF- header
ZIP Archive	.zip	50 4B 03 04	0x00	Local file header signature
RAR Archive	.rar	52 61 72 21 1A 07	0x00	Rar! marker block
7-Zip Archive	.7z	37 7A BC AF 27 1C	0x00	7z signature header
ELF Executable	n/a	7F 45 4C 46	0x00	Linux/Unix executable format
PE Executable	.exe	4D 5A	0x00	DOS MZ header (Windows PE)
Mach-O (64-bit)	n/a	CF FA ED FE	0x00	macOS 64-bit executable
GZIP	.gz	1F 8B	0x00	GZIP compressed data
BMP Image	.bmp	42 4D	0x00	BM bitmap header
WAV Audio	.wav	52 49 46 46	0x00	RIFF container (WAVE follows at 0x08)
MP3 Audio	.mp3	FF FB or 49 44 33	0x00	MPEG frame sync or ID3v2 tag
MP4 Video	.mp4	66 74 79 70	0x04	ftyp box (offset 4, size at 0x00)
WebP Image	.webp	52 49 46 46	0x00	RIFF container (WEBP at 0x08)
SQLite Database	.db/.sqlite	53 51 4C 69 74 65	0x00	"SQLite format 3\000"
WASM Binary	.wasm	00 61 73 6D	0x00	WebAssembly magic + version
Java Class	.class	CA FE BA BE	0x00	Java bytecode identifier
TAR Archive	.tar	75 73 74 61 72	0x101	"ustar" at offset 257

Frequently Asked Questions

The entire file is loaded into a single ArrayBuffer via the File API, which means the practical limit is your browser's memory allocation (typically 1-2 GB on desktop, less on mobile). The DOM remains lightweight because only 256 bytes are rendered at a time via pagination. For files exceeding ~500 MB, expect a loading delay of several seconds.

Bytes outside the printable ASCII range (0x20-0x7E) are replaced with a period (.) for display safety. Control characters (0x00-0x1F) and extended bytes (0x80-0xFF) have no universal visual glyph and can break text layout or trigger terminal escape sequences. The dot convention matches standard hex dump tools like xxd and HxD.

Load the file and inspect the first 4-8 bytes on page 0. Compare these hex values against the reference table above. For example, if you see 89 50 4E 47 at offset 0x00, the file is a PNG image regardless of its extension. Some formats like MP4 place the type indicator at offset 0x04 (the "ftyp" box), so check the specification for non-zero offsets.

Endianness determines byte order for multi-byte values. Little-endian (LE) stores the least significant byte first - used by x86/x64 CPUs and most modern file formats (ELF, WAV, BMP). Big-endian (BE) stores the most significant byte first - used in network protocols (TCP/IP), Java class files, and PNG chunks. The inspector shows both interpretations so you can match the format's specification.

Yes. The search supports both hex patterns (e.g., '89504E47') and ASCII text strings (e.g., 'RIFF'). When searching as text, each character is converted to its byte value using charCodeAt(). Note that this only works for single-byte encodings (ASCII/Latin-1). Multi-byte UTF-8 characters will not match correctly - use hex search for those.

No. The tool operates entirely client-side using the browser's File API and ArrayBuffer. No network requests are made. The file is read into memory within your browser tab and discarded when you close or reload the page. No data is stored in localStorage - only UI preferences like bytes-per-row and last search mode.