Hex Dump Viewer
How it works
A hex dump displays the binary content of a file or data stream as hexadecimal values, arranged in rows of 16 bytes with ASCII representation alongside. Hex dumps are the primary tool for inspecting binary files, debugging data encoding issues, analysing file formats, and forensic examination of data. Every hex editor and debugging environment shows data in this format.
**Hex dump format** Each line shows: byte offset (column position in the file), up to 16 hex byte values (each byte as two hex digits, space-separated), and the ASCII representation of those 16 bytes (non-printable characters shown as "."). Example: ``` 00000000: 89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 .PNG........IHDR 00000010: 00 00 02 80 00 00 01 e0 08 02 00 00 00 73 51 a4 .............sQ. ``` The first line shows a PNG file's magic bytes (89 50 4e 47 = ‰PNG) and IHDR chunk header.
**Magic bytes / file signatures** Many file formats start with a unique byte sequence: PNG (89 50 4E 47), JPEG (FF D8 FF), PDF (25 50 44 46 = %PDF), ZIP/DOCX/XLSX (50 4B 03 04 = PK), EXE (4D 5A = MZ). A hex dump of the first 16 bytes identifies the true file type — regardless of file extension, which can be renamed arbitrarily.
**Encoding debugging** When a text file displays garbled characters, a hex dump reveals whether it uses UTF-8 (multi-byte sequences starting with C2–F4), UTF-16 (BOM: FF FE or FE FF), Windows-1252 (single bytes 80–9F for special characters), or corrupt encoding.
**Input formats accepted** The viewer accepts: file upload (any binary file); pasted hex string (space or no separator); base64-encoded data; and plain text (displayed as UTF-8 bytes).
Privacy: all data is processed locally in the browser. No file contents are transmitted.
Frequently Asked Questions
- Look at the first 4–8 bytes (the 'magic bytes'): PNG starts with 89 50 4E 47 (‰PNG in ASCII). JPEG: FF D8 FF. GIF: 47 49 46 38 ('GIF8'). PDF: 25 50 44 46 ('%PDF'). ZIP/DOCX/XLSX: 50 4B 03 04 ('PK', named after Phil Katz). EXE/DLL (Windows): 4D 5A ('MZ', named after Mark Zbikowski). ELF (Linux executable): 7F 45 4C 46. MP3: 49 44 33 ('ID3') or FF FB. These 'magic numbers' are why renaming a file extension doesn't change its actual type — the content determines the type.
- Zero-width characters are Unicode code points that don't render visibly but occupy bytes in the string. Common ones: Zero Width Space (U+200B) = E2 80 8B in UTF-8 (3 bytes). Zero Width Non-Joiner (U+200C) = E2 80 8C. Zero Width Joiner (U+200D) = E2 80 8D. BOM/Zero Width No-Break Space (U+FEFF) = EF BB BF in UTF-8. In a hex dump, these appear as non-ASCII byte sequences with no ASCII representation character (shown as dots). They can hide watermarks in leaked documents — different people receive copies with different zero-width character patterns inserted.
- Binary is too verbose (one byte = 8 binary digits vs. 2 hex digits). Decimal is awkward because bytes don't align to decimal digit boundaries (256 values per byte, not a power of 10 — you'd need 3 decimal digits per byte but many bytes use fewer). Hexadecimal is ideal: one nibble (4 bits) = one hex digit, two nibbles (8 bits = 1 byte) = exactly two hex digits. Hex digits map directly to binary: 0=0000, F=1111. Experienced programmers can read binary from hex mentally: 0xA0 = 1010 0000.
- Convert the search string to ASCII byte values: 'hello' = 68 65 6C 6C 6F. Search for this byte pattern in the hex dump. For UTF-16 encoded strings (common in Windows executables and .NET binaries): each character is 2 bytes with a null byte between — 'hello' in UTF-16LE = 68 00 65 00 6C 00 6C 00 6F 00. For Unicode strings, the hex dump viewer can search in UTF-8, UTF-16LE, or UTF-16BE simultaneously. The byte offset displayed on each row's left side tells you exactly where in the file the match occurs.