Hex File Viewer
View any file as a hex dump with ASCII column.
Drop any file here
or
Your file never leaves your browser.
This tool renders any file as the classic hex dump: offset column, sixteen hex bytes per row, and an ASCII sidebar for spotting embedded strings. Files load lazily in 16 KB pages, so even huge binaries open instantly — the first screen is usually enough to identify a mystery file by its magic bytes.
How it works
The viewer slices the file with the browser's File API — only the pages you have scrolled to are ever read from disk — and formats each 16-byte row as offset, hex values and printable ASCII. The layout is byte-exact with command-line tools like xxd and hexdump -C, so offsets you find here can be used directly in scripts, dd commands or firmware notes.
Worked example
→ the first 8 bytes identify a PNG; “IHDR” names its first chunk
Parameters
| Parameter | Value | Notes |
|---|---|---|
| Row format | offset · 16 bytes hex · ASCII | xxd-compatible |
| Paging | 16 KB per load | lazy File.slice reads |
| Printable range | 0x20 – 0x7E | others shown as “.” |
| File size | unlimited | never fully loaded |
Python implementation
# The same view on the command line
# xxd firmware.bin | head
# or in Python:
def hexdump(data: bytes, base=0, width=16):
for off in range(0, len(data), width):
chunk = data[off:off + width]
hexs = " ".join(f"{b:02X}" for b in chunk)
text = "".join(chr(b) if 32 <= b <= 126 else "." for b in chunk)
print(f"{base + off:08X} {hexs:<47} |{text}|")FAQ
▸How do I read the three columns?
Left: the byte offset from the start of the file, in hex. Middle: sixteen bytes per row as two-digit hex values, with a gap after the eighth for easy counting. Right: the same bytes as ASCII, with anything non-printable shown as a dot — the column where magic strings and embedded text jump out.
▸What are magic numbers and where do I look for them?
Most file formats open with a fixed signature in the first bytes: 89 50 4E 47 for PNG, 25 50 44 46 ('%PDF'), 50 4B for ZIP-based formats, 'TDSm' for TDMS. The first row of the dump usually identifies an unknown file immediately.
▸Can it handle large files?
Yes — the file is read lazily in 16 KB pages with the File API, so opening a gigabyte file is instant; you page through as far as you need. Nothing is ever loaded fully or uploaded.
▸Why do I see 0xFF padding at the end of firmware dumps?
Erased flash memory reads as all-ones, so unprogrammed regions of a firmware image appear as runs of FF. Long FF runs mark the boundary between code/data and unused flash.
▸Is my file uploaded?
No. Slicing and rendering run entirely in your browser.