Hex Dump Viewer Online

How to View a Hex Dump Online

1. Load Bytes: Drag and drop a file (or paste raw text / Base64 / hex) into the input. The viewer streams the bytes locally and renders the classic three-column dump — offset, hex bytes, and ASCII gutter. Files never leave your browser.
2. Pick Row Width and Base (Optional): The default is 16 bytes per row in lowercase hex with an 8-character offset, matching hexdump -C and xxd output. Switch to 8, 24, or 32 bytes per row when scanning fixed-width records, flip hex to UPPERCASE for documentation, or change the offset format to decimal when correlating with file-size math.
3. Toggle the ASCII Gutter (Optional): The right-hand column shows printable ASCII (0x20–0x7E) and a . placeholder for control bytes and high-bit characters. Hide it for narrower output; keep it on to spot text strings, magic bytes (PK.., %PDF, ID3), and section names embedded in binaries.
4. Read or Copy: Scroll through the dump, search for byte patterns or offsets, and copy any selection as plain text. Useful for incident reports, bug-tracker pastes, or saving the dump alongside the original file in a forensics evidence bundle.

Why View a Hex Dump?

Every file on disk is just a byte sequence, and a hex dump is the universal lens for inspecting that sequence without trusting the extension. The first 4–8 bytes alone usually identify the format (PNG, PDF, ZIP, ELF), the next region carries headers and metadata, and embedded strings often reveal author, tool, or compromise. Common reasons people open a hex dump:

• Identifying an unknown or mis-extensioned file — A .doc that's actually a ZIP (any .docx renamed), or a "JPG" that's really an HTML phishing page, reveals itself in the first 4 bytes. PNGs start with 89 50 4E 47 0D 0A 1A 0A, PDFs with 25 50 44 46 (%PDF), ZIPs with 50 4B 03 04 (PK\x03\x04).
• Debugging file corruption — When an upload truncates, the EOF marker (%%EOF for PDF, IEND for PNG, FF D9 for JPEG) is missing or shifted. A dump shows exactly where the bytes stop versus where they should stop.
• Forensics and incident response — CTF challenges, malware triage, and disk-image analysis all start with a hex view to locate magic bytes, embedded executables, and unusual entropy. Carving tools like binwalk and foremost use the same signature table internally.
• Reverse engineering protocols and wire formats — Reading a captured packet, an undocumented binary log, or a proprietary save file is impossible from a text editor. A hex view reveals length-prefixed fields, padding, and endianness at a glance.
• Verifying encoders and writers — When implementing a Protobuf, BSON, MessagePack, or PNG writer, you compare the bytes your code produces against a reference implementation. Diffing two hex dumps surfaces off-by-one length fields and bad endianness instantly.
• Inspecting embedded metadata — JPEG EXIF, ID3 tags in MP3s, IPTC blocks, and PDF object streams all sit at known offsets and have ASCII landmarks (Exif, ID3, Photoshop) that pop out of the ASCII gutter.

Working with text content instead? Use Text Diff to compare two strings, Base64 Decoder to unwrap encoded payloads before dumping, or Hash Generator to fingerprint a file alongside its hex view.

Magic Bytes — Identify a File from Its First Bytes

The hex bytes at offset 0 (the "magic number") are the most reliable file-type signal. Below are the canonical signatures most tools check — extensions can lie, magic bytes rarely do.

Format	Hex bytes at offset 0	ASCII gutter	Source
PNG	89 50 4E 47 0D 0A 1A 0A	.PNG....	W3C PNG specification
JPEG (JFIF)	FF D8 FF E0	....	JFIF / Exif standard
JPEG (Exif)	FF D8 FF E1	....	CIPA DC-008 Exif
GIF	47 49 46 38 39 61 or …37 61	GIF89a / GIF87a	W3C / CompuServe spec
PDF	25 50 44 46 2D	%PDF-	ISO 32000
ZIP / DOCX / XLSX / JAR	50 4B 03 04	PK..	PKWARE APPNOTE
GZIP	1F 8B	..	RFC 1952
7-Zip	37 7A BC AF 27 1C	7z....	7-Zip spec
RAR (v5)	52 61 72 21 1A 07 01 00	Rar!....	RARLAB technote
ELF (Linux executable)	7F 45 4C 46	.ELF	System V ABI
Mach-O 64-bit	CF FA ED FE	....	Apple loader.h
PE / Windows EXE	4D 5A (then PE at offset 0x3C)	MZ	Microsoft PE/COFF spec
MP3 with ID3v2 tag	49 44 33	ID3	ID3.org
MP4 / MOV	?? ?? ?? ?? 66 74 79 70	....ftyp	ISO/IEC 14496-12
WAV / RIFF	52 49 46 46 ?? ?? ?? ?? 57 41 56 45	RIFF....WAVE	IBM/Microsoft RIFF
BMP	42 4D	BM	Microsoft BMP spec
Class file (Java)	CA FE BA BE	....	JVM spec
SQLite database	53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00	SQLite format 3.	sqlite.org

Hex Dump Format — How Common Tools Differ

Different tools render the same bytes with different layouts. Knowing which produced a given paste helps you locate offsets quickly.

Tool	Default row width	Offset base	ASCII column	Notes
xxd (Vim)	16 bytes	hex, 8 digits	yes, |...| delimiters	Reversible with xxd -r; canonical for hex editing
hexdump -C (BSD/Linux)	16 bytes	hex, 8 digits	yes, |...| delimiters	The "canonical" form; gap after byte 8
hexdump (no flags)	16 bytes as 8× 2-byte words	hex	no	Little-endian word reorder catches people off guard
od -A x -t x1z	16 bytes	hex	yes, >...< delimiters	The POSIX-portable choice
od -c	16 bytes	octal	shows escapes (\n, \t)	Default od output is octal-everywhere — confusing
Python binascii.hexlify(b)	one long line	none	no	Round-trip with unhexlify; no offset or ASCII
certutil -encodehex (Windows)	16 bytes	hex, 8 digits	yes	Built into every Windows since 7
GHex / wxHexEditor / HxD	configurable	hex	yes	Edit-in-place GUIs; same three-column model

Frequently Asked Questions

What is the offset column for?

The leftmost column is the byte position from the start of the file, almost always in hexadecimal. Line one starts at 00000000, line two at 00000010 (= decimal 16, because each row holds 16 bytes), line three at 00000020 (= 32), and so on. To find the absolute position of a byte you spotted in the middle of a row, add its column index (0–15) to the row's offset. If the page tells you a header field lives at offset 0x18, that's the 25th byte from the start (decimal 24), which appears in row 0x10 at column 8.

Why does the ASCII gutter show dots for some bytes?

Only the printable range 0x20 (space) through 0x7E (~) maps to a glyph in standard ASCII. Bytes 0x00–0x1F are control characters (NUL, TAB, LF, CR, etc.) and bytes 0x7F–0xFF are either DEL or outside ASCII entirely. Most hex viewers, including xxd and hexdump -C, render every non-printable byte as a single . so the column stays aligned at one character per byte. The dot is purely visual — the underlying byte in the hex column is still its original value.

Does endianness matter when reading a hex dump?

Yes, but only when you interpret consecutive bytes as a multi-byte number. Single bytes have no endianness. If you see the four bytes 78 56 34 12, that's the 32-bit value 0x12345678 on a little-endian system (x86, x86-64, ARM in LE mode) and 0x78563412 on a big-endian system (older PowerPC, most network protocols, JPEG/PNG length fields). Tools dump bytes in storage order, so you reorder them yourself to interpret integers, floats, and timestamps. PNG, JPEG, and TCP/IP headers use big-endian; most filesystems on disk and most modern CPUs are little-endian.

How do I identify an unknown file from its hex dump?

Read the first 4–16 bytes and match them against the magic-bytes table above. If those bytes are 89 50 4E 47, it's a PNG regardless of extension; 50 4B 03 04 is a ZIP family (which covers .zip, .docx, .xlsx, .pptx, .jar, .apk, .epub, .odt, and dozens more — all are ZIP containers under the hood); 25 50 44 46 is a PDF. For containers like .docx, the next clue is the [Content_Types].xml string a few hundred bytes in. Tools like file (Linux/macOS) and TrID match the same signatures programmatically.

What's the difference between ASCII and UTF-8 byte values?

For code points 0x00–0x7F, ASCII and UTF-8 are byte-identical — a hex dump can't tell them apart. Above 0x7F, UTF-8 uses two to four bytes per character with a defined leading-byte pattern (110xxxxx 10xxxxxx for two-byte sequences, 1110xxxx 10xxxxxx 10xxxxxx for three-byte, etc.). If you see bytes like E2 9C 93 (UTF-8 for ✓) in the hex column, the ASCII gutter will show ... because none of those bytes are printable ASCII. The UTF-8 BOM (EF BB BF) at the very start of a file is a strong hint the encoding is explicitly UTF-8.

I'm editing a binary in a hex editor — what about checksums?

Most binary formats include a checksum or CRC that gets invalidated the moment you change a byte. PNG has a CRC-32 per chunk (you must recompute the chunk's CRC after edits); ZIP has a CRC-32 per entry and a central-directory checksum; PE executables have an optional header checksum; ELF doesn't checksum but signed binaries break their signature on any edit. PDFs use a cross-reference table with byte offsets — inserting or removing bytes shifts every later offset and corrupts the xref. Before editing, look up the format's checksum scheme; many tools (pngcheck, advzip, pesign) can fix or verify after the fact.

Why is the file size or offset in my dump different from the OS file size?

A few common causes. (1) Your viewer is showing bytes-per-row in 8 instead of 16, doubling the line count — the file size is identical, the layout differs. (2) The offset column is displayed in decimal rather than hex; row 16 ends at offset 256 decimal but 0x100 hex. (3) The file was read from a stream that includes a BOM or HTTP headers prepended. (4) On Windows, files opened in text mode silently convert \r\n to \n; always open in binary mode (rb) for hex dumps to match disk reality.

Can I paste hex back to bytes (round-trip)?

Yes — xxd -r reverses an xxd dump back to the original binary, and Python's binascii.unhexlify or bytes.fromhex round-trips a contiguous hex string. The catch: tools expect the exact same layout they produce. A dump pasted from hexdump -C won't reverse with xxd -r without first stripping the ASCII gutter and the offset gap. If you only have the hex column (no offsets, no ASCII), bytes.fromhex(re.sub(r'\s+', '', text)) in Python is the simplest round-trip.

Is my file uploaded anywhere?

No. The viewer runs entirely in your browser via the FileReader API — bytes are read into memory locally and rendered to the page. Nothing is transmitted to a server, no account is required, and there are no file-size watermarks or upload caps beyond what your browser tab can hold in memory (typically several hundred MB before the tab slows down).