Hex Dump
Classic 16-byte-per-line hex + ASCII dump of any file.
Overview
The hex dump renders any file as the classic 16-bytes-per-line layout: a hexadecimal offset, the bytes themselves in hex, and the printable ASCII representation on the right. It is the same format xxd and hexdump -C produce, in your browser, on any file you can upload.
Reverse engineers, firmware tinkerers, and forensic analysts reach for this when a file's magic bytes need a quick eyeball or when a binary record layout has to be picked apart by hand. Long-tail searches that lead here include "online hex viewer", "view binary file as hex", and "hexdump file in browser".
How it works
The dump format is straightforward: every 16 input bytes produce one output line. The leading column is the byte offset in hexadecimal (00000000, 00000010, 00000020, …). The middle columns show those 16 bytes as space-separated two-digit hex values, typically split into two groups of eight for readability. The trailing column shows the same bytes interpreted as printable ASCII, with non-printable values rendered as a dot.
The format is loss-free and unambiguous — every byte of the source appears in exactly one position. That makes it ideal for spotting fixed signatures (50 4B for ZIP, 25 50 44 46 for PDF, 89 50 4E 47 for PNG), embedded strings, or unusual padding.
Examples
- Confirm a downloaded file really is a PNG by checking the first eight bytes against
89 50 4E 47 0D 0A 1A 0A. - Spot a UTF-8 BOM (
EF BB BF) at the start of a text file. - Find an embedded version string in a firmware image.
- Read the header of a
.docx(which begins with50 4B 03 04, the ZIP local file header).
FAQ
How large a file can I dump?
Practical limits are governed by browser memory. For files into the hundreds of megabytes, prefer a desktop tool; for typical configuration files, headers, and small binaries, the in-browser dump is comfortable.
Can I jump to a specific offset?
The output is generated as a single block. Use your browser's find-in-page to jump to a hex offset (e.g. search for 00001000).
Why does the ASCII column show so many dots?
Non-printable bytes (control characters, multi-byte sequences, binary data) are rendered as . to keep alignment. Long runs of dots usually indicate compressed, encrypted, or non-text payload.
Does the dump preserve newlines and spaces?
Yes — every byte is shown literally. Spaces appear as 20 and newlines as 0A (or 0D 0A on Windows-line-ending files).
Is there a Base64 alternative?
For passing binary through text channels, see the dedicated Base64 encoder. The hex dump is for human inspection, not transport.