🔣 Hex Dump Viewer, Text to Hex Dump with Offset and ASCII

What is the Hex Dump Viewer?

A hex dump shows you the exact bytes that make up some data, which is invaluable when characters that look identical on screen are actually different under the hood. Each byte is one value from 0 to 255, written as two hexadecimal digits (00 to FF). Reading text as hex lets you spot a hidden tab, a Windows carriage return before a line feed, a byte-order mark, or a smart quote that a plain editor would never reveal. Programmers, reverse engineers and protocol debuggers reach for hexdump output constantly for exactly this reason, and it is one of the first things people learn when they start working with binary data or network packets.

The layout here follows the convention popularised by Unix tools such as hexdump -C and xxd. The first column is the offset: the position of the first byte on that row, counted from the start and printed in hex, zero-padded to at least eight digits. Because each row holds 16 bytes by default, the offsets step up by 16 (0x10) each line: 00000000, 00000010, 00000020, and so on. The middle block prints those 16 bytes as space-separated hex pairs. The final block, framed by pipe characters, is the ASCII gutter: every byte in the printable range (0x20 space through 0x7E tilde) is shown as its character, and everything else becomes a dot so the columns stay aligned.

The one subtlety worth understanding is encoding. Text on the web is not stored as characters but as bytes, and the mapping between them is the character encoding. This tool uses UTF-8, the dominant encoding of the modern web and the default for HTML, JSON and most APIs. In UTF-8 the plain ASCII letters each take a single byte, so 'A' is 41 and 'z' is 7A, but accented letters, emoji and most non-Latin scripts take two, three or four bytes each. That is why a single visible emoji can fill four hex pairs and show up as four dots in the ASCII gutter: it is one character but several bytes. This is also why a hex dump of the same sentence in UTF-8 versus UTF-16 or Latin-1 produces a different, non-interchangeable byte stream, so always confirm which encoding you are comparing against before assuming two dumps should match.

Hex dumps and hex editors solve related but different problems. A hex dump is a read-only, one-way rendering: you feed in text or a file and get back a static view of its bytes, useful for inspection, debugging and documentation. A hex editor lets you open a binary file, navigate to a specific offset, and overwrite individual bytes, which is what you would reach for to patch a save file, repair a corrupted header, or reverse-engineer a proprietary file format. This tool is a dump, not an editor, by design; it never writes anything back, which keeps it safe to run on sensitive text and to use for teaching without any risk of accidentally corrupting a real file.

Understanding hex is also foundational for reading other byte-level formats you will meet in web development. Base64, used to embed images in CSS or attach binary data to JSON, is really just another encoding of the same underlying bytes a hex dump shows you, only using 64 printable characters instead of 16. A URL-encoded percent sequence like %20 for a space is the hex byte 0x20 with a percent sign in front. Once you can read a hex dump fluently, decoding a Base64 string, a percent-encoded URL, or a raw TCP payload in Wireshark becomes far less mysterious, because they are all different textual dresses on the same underlying byte values.

Hexadecimal itself is base 16, using the digits 0 through 9 and the letters A through F to represent values 0 through 15. It exists because it maps cleanly onto binary: one hex digit represents exactly four bits, so a full byte (8 bits) is always exactly two hex digits, with no rounding or ambiguity. That clean mapping is why hex, rather than decimal, became the standard way to display raw memory and file contents across every operating system and programming language.

When to use it

• Spotting invisible characters such as tabs, trailing spaces, carriage returns or a byte-order mark that a normal text editor hides.
• Teaching or learning how UTF-8 encodes ASCII, accented letters and emoji into one or more bytes each.
• Inspecting the exact bytes of a token, key fragment or protocol message while debugging an API or parser.
• Producing a clean hexdump to paste into a bug report, forum question or code review so others see the precise bytes.
• Checking whether two strings that look identical are actually different by comparing their byte-level hex dumps side by side.
• Verifying line-ending style (Unix LF versus Windows CRLF) before committing a file or diffing text across operating systems.

How to use the Hex Dump Viewer

1. Type or paste your text into the input box.
2. Optionally tick Uppercase hex or change how many bytes appear per row (8, 16 or 32).
3. Press Make hex dump to generate the offset, hex and ASCII columns.
4. Read the dump or press Copy to put it on your clipboard.
5. If a byte looks unexpected, cross-check it against the reference table below to confirm what character or control code it represents.

Formula & method

Worked examples

Common bytes and how they appear in the dump

Hexadecimal, decimal and binary for one byte

Common mistakes to avoid

• Expecting one byte per character. Only plain ASCII maps to a single byte in UTF-8. Accented letters take two bytes, most symbols and CJK characters take three, and emoji take four, so the byte count is often larger than the character count.
• Confusing the offset with a byte count. The left column is the position of the first byte on that row, not a tally. With 16 bytes per row the offsets jump by 16 (0x10) each line: 00000000, 00000010, 00000020.
• Reading dots as literal periods. A dot in the ASCII gutter means the byte was outside the printable range (below 0x20 or above 0x7E), not that the data contained a period. An actual period is the byte 0x2E, shown as 2e in the hex column.
• Assuming the encoding is something other than UTF-8. This tool always encodes as UTF-8. The same text in Latin-1, UTF-16 or another encoding would produce different bytes, so compare like with like when matching against another dump.
• Treating a hex dump viewer like a hex editor. This tool only reads and displays bytes, it never lets you overwrite them or save a modified binary. If you need to patch an actual file byte-by-byte you need a dedicated hex editor, not a dump viewer.
• Forgetting that hex is case-insensitive but not always displayed consistently. The hex value 4a and 4A represent the exact same byte. Some tools default to lowercase and others to uppercase, so if you are comparing dumps character by character, normalise the case first rather than assuming a mismatch.

Glossary

Hex dump

A view of raw data as hexadecimal byte values, usually alongside an offset column and an ASCII gutter.

Byte

A unit of data holding a value from 0 to 255, written here as two hexadecimal digits (00 to FF).

Offset

The position of a byte counted from the start of the data, shown in hex in the left column.

Hexadecimal

Base-16 notation using the digits 0 to 9 and letters a to f, where one hex digit covers four bits.

ASCII gutter

The right-hand column that prints each printable byte as its character and replaces non-printable bytes with a dot.

UTF-8

The dominant text encoding of the web, using one to four bytes per character and matching ASCII for the first 128 codes.

Byte-order mark (BOM)

An optional invisible marker (EF BB BF in UTF-8) some editors add at the very start of a text file to signal its encoding.

Hex editor

A tool that lets you view and directly overwrite the raw bytes of a file, unlike a read-only hex dump viewer.

Frequently asked questions