Hex Viewer

View the raw bytes of any file or string as a classic hex dump. Each line shows an 8-digit offset, the bytes in hex grouped for readability, and an ASCII gutter where printable characters appear and everything else shows as a dot. Choose 8, 16, or 32 bytes per row, load a file directly, or paste text to dump its UTF-8 encoding. The file is read with FileReader in your browser and never uploaded, so you can inspect headers, magic numbers, and binary payloads privately.

How to use the Hex Viewer

Pick any file with the file chooser, or paste text into the box to dump the bytes of its UTF-8 encoding. The dump appears immediately with the total file size shown above it. Use the Bytes per row selector to switch between 8, 16, and 32 bytes per line. Sixteen is the traditional width that matches most documentation and the output of the Unix xxd and hexdump -C commands; eight is easier to read on a phone; thirty-two packs more onto a wide screen.

Read the dump left to right: the first column is the byte offset in hex, counting from zero at the start of the file. The middle block is the bytes themselves, two hex digits each, grouped with extra spacing so you can count positions at a glance. The right-hand ASCII gutter renders each byte as its printable character when it falls in the 0x20–0x7E range and as a dot otherwise, which makes embedded strings such as filenames, URLs, or format tags jump out of otherwise opaque binary. Very large files are capped at the first 256 KB of displayed output so the page stays responsive; the size readout still reflects the whole file, and a note tells you when the view was truncated.

Hex dumps, bytes, and the ASCII gutter

A hex dump is a way of showing the exact contents of a file one byte at a time. Every byte is eight bits, a value from 0 to 255, and the cleanest way to write that range is two hexadecimal digits. Hex is base-16, so each digit covers four bits — a nibble — and a pair of nibbles is exactly one byte. That is why FF is 255 and 00 is zero: the format maps one byte to two characters with no ambiguity, unlike decimal where byte boundaries are invisible. Reading bytes as hex is the only faithful view of binary data, because text editors silently reinterpret, re-encode, or hide bytes they do not understand.

The offset column on the left is the running position from the start of the file, also in hex. Offsets let you describe a location precisely ("the magic number is at offset 0 and the size field at offset 0x10") and line up a dump against a format specification. The ASCII gutter on the right is the human-friendly companion: control bytes and high bytes become dots, but any run of printable text shows through, so you can spot strings without decoding the whole file. Together the three columns — offset, hex, gutter — are the standard layout produced by tools like xxd, hexdump -C, and most hex editors.

One of the most common reasons to reach for a hex view is checking a file's magic number, the short signature most formats place in their first few bytes. PNG files begin with 89 50 4E 47 (the bytes spell .PNG in the gutter), JPEG with FF D8 FF, a PDF with 25 50 44 46 (%PDF), a ZIP archive with 50 4B 03 04 (PK..), and an ELF binary with 7F 45 4C 46. Because extensions lie and MIME types can be wrong, the bytes are the source of truth: a hex view tells you what a file actually is, lets you confirm an encoding, debug a corrupted header, or verify that a tool wrote the structure you expected.

Common use cases

• Identifying a file. Read the first bytes to confirm the real format from its magic number, regardless of the extension.
• Debugging binary output. Check that a program wrote the exact header, length fields, or padding you expected.
• Inspecting encodings. See whether text is UTF-8, has a byte-order mark, or contains stray control characters.
• Finding embedded strings. Scan the ASCII gutter for URLs, filenames, or tags hidden inside a binary blob.
• Private review. Examine a sensitive or unknown file locally instead of uploading it to an online hex tool.