ABC Tools

The Hex Viewer, Explained

After reading this you will be able to read any file as a grid of offsets, hex bytes and ASCII, identify a file's real type from its first bytes, and avoid the common traps of encoding and endianness.

What a hex viewer shows you

Every file on disk is a sequence of bytes. A byte is 8 bits, so it holds one of 256 values, from 0 to 255. Text editors hide this by decoding those bytes into letters. A hex viewer does the opposite: it shows the raw bytes and lets the meaning stay explicit.

The classic layout has three columns. On the left is the offset, the position of the first byte on that row, written in hexadecimal. In the middle is the hex column, usually 16 bytes per row, each shown as two hex digits. On the right is the ASCII column, which prints each byte as a character when it is printable and a dot otherwise.

Here is the hook. Suppose someone hands you a file named photo.png. Open it and look at the first four bytes. If they read 89 50 4E 47, it really is a PNG. If they read 25 50 44 46, the ASCII column shows %PDF and the file is a PDF wearing the wrong extension. The bytes never lie; the name can.

Hexadecimal and why bytes use it

Hexadecimal is base 16. Its digits are 0 through 9 then A through F, where A is 10 and F is 15. One hex digit covers 4 bits (values 0 to 15). Two hex digits cover 8 bits, which is exactly one byte.

To convert a two-digit hex value to decimal, multiply the first digit by 16 and add the second.

v = 16 \cdot d_1 + d_0

Here d_1 is the high (left) digit and d_0 is the low (right) digit, each from 0 to 15. Take 4E: the high digit is 4 and the low digit is E = 14, so v = 16 \cdot 4 + 14 = 78. Decimal 78 is the ASCII code for the letter N, which is why the PNG magic ends in N.

Offsets use the same base. The offset 0x10 means 16 \cdot 1 + 0 = 16 bytes into the file. The offset 0x100 is 16^2 = 256. Reading offsets in hex keeps them aligned with the 16-byte rows: each new row bumps the offset by exactly 0x10.

When to reach for it, and when not

Use a hex viewer when the bytes themselves are the question. Good cases: confirming a file's real type, finding where one format is embedded inside another, checking that a header field holds the value you expect, spotting a stray byte order mark, or seeing whether a "text" file is UTF-8 or UTF-16.

Do not use it to read prose or edit large documents. Sixteen bytes per row means a 2 KB paragraph spans 128 rows, and you lose the sentence. For structured data with a known schema, a parser that understands the format will tell you more than raw bytes. The hex view is for the layer below the parser, when you need to check what the parser is actually being fed.

When a program refuses to open a file, the first 16 bytes usually explain why in seconds. A truncated download often ends early or starts with an HTML error page (3C 21 44 4F, which is <!DOctype) instead of the expected magic bytes.

A worked example: reading the demo bytes

The demo loads a small file. Suppose its first 16 bytes are the classic PNG signature followed by the start of the header chunk:

Decoding the first row

The row at offset 00000000 reads:

89 50 4E 47 0D 0A 1A 0A 00 00 00 0D 49 48 44 52

  1. 89 is a non-ASCII byte on purpose. It is above 127, so it survives text transfers that would corrupt a plain 7-bit file. The ASCII column shows a dot.
  2. 50 4E 47 decode to P, N, G. Using the formula, 50 = 16 \cdot 5 + 0 = 80, and ASCII 80 is P.
  3. 0D 0A is a carriage return plus line feed. This pair is placed here so that if the file is mangled by a system that rewrites line endings, the damage shows up immediately.
  4. 1A is the DOS end-of-file marker, and the second 0A catches the reverse line-ending conversion.
  5. 00 00 00 0D is a 4-byte big-endian integer equal to 13. It is the length of the chunk that follows.
  6. 49 48 44 52 decode to IHDR, the image header chunk name.

So one row of 16 bytes tells you the type, its integrity guards, and the size and name of the first chunk. The ASCII column shows .PNG....​....IHDR, and the leading dots are the non-printable bytes.

Big-endian, little-endian, and multi-byte values

A single byte has no ordering problem. Numbers wider than one byte do. The value 13 above was stored as 00 00 00 0D, most significant byte first. That is big-endian. Many file formats and network protocols use it.

Intel CPUs store multi-byte integers the other way, least significant byte first, called little-endian. The same 32-bit value 13 would appear as 0D 00 00 00. To read a little-endian value in the hex column, reverse the byte order before applying place value.

v = \sum_{i=0}^{n-1} b_i \cdot 256^{\,i}

Here b_i is the byte at position i counting from the least significant end, and n is the number of bytes. For little-endian 0D 00 00 00, b_0 = 13 and the rest are 0, giving v = 13. For big-endian, feed the bytes in reversed order into the same sum.

The number 13 stored two ways. Big-endian puts the meaningful byte last, little-endian puts it first.

Enter up to four hex bytes such as 0D 00 00 00. Read as little-endian it is 13; read as big-endian it is 218103808. Reversing the byte order swaps the two interpretations.

Text encodings in the ASCII column

The ASCII column only decodes one byte at a time, so it tells the truth for 7-bit ASCII and lies gently for everything else. That is useful, because the pattern of dots and letters reveals the encoding.

ASCII / UTF-8 for plain English
The bytes match the letters directly. Hi is 48 69, one byte each.
UTF-8 with accents or emoji
Characters above U+007F use two to four bytes, each in the range 0x80 to 0xFF. The letter é is C3 A9, shown as two dots.
UTF-16
Every ASCII letter is padded with a 00 byte. The word Hi in UTF-16 little-endian is 48 00 69 00, so the ASCII column shows a letter, a dot, a letter, a dot.

A byte order mark makes this explicit. UTF-8 files may begin with EF BB BF. UTF-16 little-endian begins with FF FE, and big-endian with FE FF. If you see FF FE at offset 0 followed by letters separated by zeros, you are looking at UTF-16.

Common mistakes when reading hex

Do not assume the ASCII column tells you the encoding. A run that reads like garbage may be perfectly valid compressed or encrypted data. Absence of readable text is not corruption.

Three traps catch people repeatedly. First, confusing hex and decimal offsets: 0x20 is 32, not 20. Second, reading a multi-byte number without knowing its endianness, which can turn 13 into 218103808. Third, treating the 16-byte row width as meaningful. It is a display choice, not part of the file. A field can start in the middle of a row and continue into the next, so track the offset, not the visual grid.

One more: a file's size in bytes is exact, but tools often report it in KB or MB with rounding. If a header says a chunk is 0x0D bytes long, that is precisely 13 bytes, and you can count them in the hex column to confirm.

Related tools

Once you have identified a file, two nearby tools finish the job. If the magic bytes read 50 4B 03 04 (PK), the file is a ZIP container, and you can open it with the ZIP Creator & Extractor. Note that .docx, .xlsx and .jar all start with the same PK signature, because they are ZIP files underneath.

To confirm a download matches its published checksum, compute its digest with the File Hash Checker. The hex viewer shows you what changed; the hash tells you whether anything changed at all.

Frequently asked questions

How do I find a file's real type?

Read the first few bytes at offset 0. PNG is 89 50 4E 47, PDF is 25 50 44 46, ZIP and Office documents are 50 4B 03 04, GIF is 47 49 46 38. These signatures, called magic bytes, override the file extension.

Why are so many bytes shown as dots?

The ASCII column prints a dot for any byte that is not a printable character, that is, values below 0x20 or above 0x7E. Binary formats, compressed data and non-English text are mostly non-printable, so dots are normal.

Can I open a huge file?

Yes. Only the visible window of rows is rendered, so a 2 GB file opens as fast as a 2 KB one. Use jump-to-offset to move directly to the region you care about instead of scrolling.

Is my file uploaded anywhere?

No. The viewer runs entirely in your browser. The bytes are read locally and never leave your device, which matters when you inspect private or sensitive files.

What is the difference between hex search and text search?

Text search matches ASCII bytes, so searching PNG finds 50 4E 47. Hex search matches raw byte values, so you can find a signature like 89 50 4E 47 that includes a non-printable byte no keyboard can type.

Try it yourself in the tool

Related tools

EPUB Converter & Metadata Editor

EPUB → TXT or Markdown, edit metadata, export chapters.

File Hash Checker

SHA-256/SHA-1/MD5 of any file — verify downloads.

WhatsApp & Telegram Chat Analyzer

Upload a chat export: stats, heatmaps, reply times and a shareable dashboard card.

ZIP Creator & Extractor

Build ZIP archives and unpack them, all in the browser.

Auto Analyst: Instant Statistical Report

Drop a CSV or Excel file and get a statistician’s report: data problems, distributions, every real relationship, key drivers and Simpson’s paradox warnings, in plain English.

CSV Viewer & Editor

View, edit, sort, filter and extract columns from CSV files.