Hex Viewer

Read any file as a classic hex dump with offsets, hex columns and an ASCII pane, plus byte search, range selection and file-signature detection.

🌐 Español

Hex Viewer works on any file type — upload one above to see its raw bytes, search for a hex pattern or piece of text, and check for a known file signature.

🔒 Private by design: everything runs locally in your browser and never uploaded to any server.

Written and maintained by Last updated

From upload to a byte you can point at

  1. Click Upload a file to inspect and choose any file. There is no type restriction, and no processing is done to it beyond reading the bytes.
  2. Scroll the grid. The Offset column, the sixteen hex columns numbered 00 to 0F and the ASCII pane stay locked together on every line.
  3. To hunt for something, set Search mode to Text (UTF-8) or Hex bytes, fill in Search text or Hex pattern (e.g. 4A 50), and press Find next. Each press jumps to the following occurrence and scrolls it into view.
  4. Click a byte to select it, hold Shift and click a second one to take everything between them, or type numbers into Start offset and End offset and press Select range.
  5. Glance at the line carrying the file name for the byte count and any file signature that matched.

Sixteen bytes a row, and the dots in the right column

The layout is the one every hex dump has used since the 1970s, for the good reason that sixteen bytes per line makes offsets land on round numbers. Every line shows where it starts, then its bytes as two-digit uppercase hex, then the same bytes rendered as characters.

The character pane only renders bytes from 0x20, the space, through 0x7E, the tilde. Everything else becomes a full stop. That covers control characters like a newline or a tab, and it covers every byte from 0x7F upward, which in a UTF-8 file means every accented letter and every emoji turns into a run of dots rather than the character you would see in a text editor. This is not the viewer being lossy, it is the pane being one character wide per byte, which multi-byte encodings cannot satisfy. Read those bytes in the hex columns instead.

The practical value of the pane is pattern recognition. Text-based formats light up immediately, and a binary format’s embedded strings stand out as islands of legible characters in a sea of dots.

Two search modes over one contiguous byte array

Both modes end up at the same primitive, a byte sequence to look for. Hex mode lets you type the sequence directly, which is what you want when you are chasing a header or a known marker. Text mode encodes your typing as UTF-8 and searches for those bytes, which is what you want when you are chasing an embedded string.

Two behaviors worth knowing before you rely on the results. Find next continues from just after the previous hit, so overlapping occurrences are all reachable, and when it runs off the end it starts again from offset zero and says explicitly that it wrapped. And when nothing matches at all, it says so plainly rather than leaving the last hit highlighted, so a stale highlight never masquerades as a fresh result.

Selections, offsets and the 64-byte preview

A selection can be made by pointing or by typing, and the two stay in sync: clicking a byte fills the offset boxes with its position, and typing offsets moves the highlight and scrolls to it. Offsets typed outside the file are clamped to its last byte rather than rejected, and a reversed pair is normalized, so entering 200 and then 100 selects the same range as 100 and then 200.

The summary underneath gives you the count and the boundaries, and for a selection of 64 bytes or fewer it also prints those bytes as hex and as characters. That short-preview cutoff is deliberate. Counting bytes is the answer for a big block, and reading them is the answer for a small one, such as the eight-byte signature at the head of a PNG or the four-byte length prefix in front of a chunk.

The signature verdict beside the file name

As soon as a file loads, its opening bytes are compared against a table of well-known magic numbers, and the same line that carries the file name either names what matched or states that nothing on the list did, pointing you at the FAQ below, where the full list of checked signatures is written out. It is a curated set of the formats people most often need to recognize on sight, not a database of every format in existence.

That same table backs the File Type Identifier, which imports it from here and adds the MIME type, the canonical extension and a verdict on whether a file’s name matches its bytes. If the question you are actually asking is “what is this file”, start there; if the question is “what is inside it”, stay here. When you need an offset in a different base, the Number Base Converter reads 0x2A as 42 in decimal and 101010 in binary with its source base left on auto-detect, which picks the base up from the 0x prefix.

A viewer, not an editor, and a 100 MB ceiling

Two limits are worth stating plainly. The first is that nothing here writes: no byte editing, no patching, no saving a modified copy. The second is the 100 MB cap, which is checked once the browser has finished handing over the file and before the view is built.

Row rendering is not what that cap protects. The grid is 420 pixels tall with 24-pixel rows, so roughly seventeen lines are visible, and the component mounts at most 35 of them at a time, recomputing the window on every scroll. A file with hundreds of thousands of lines scrolls exactly like a tiny one. What the cap protects is the single flat array the whole file is held in, which is a real allocation regardless of how few lines are drawn.

For work that starts before the byte level, two neighbors help. The File Checksum Verifier answers whether a file is bit-for-bit what it should be, which is a better first question than “where does it differ” when you have a published hash to compare against. And if the bytes you are chasing arrived over the network, the HAR File Viewer reads a DevTools capture as a request table, which is a faster way to find the response you care about than reading a saved body by hand.

See it in action

Screenshot of the Hex Viewer tool with an empty file picker, with the note that it works on any file type
Hex Viewer mid-process: an empty file picker, with the note that it works on any file type.
Screenshot of the Hex Viewer result screen showing the file opened as raw bytes in a hex column beside its ASCII rendering, searchable and scrollable
The finished result: the file opened as raw bytes in a hex column beside its ASCII rendering, searchable and scrollable. The download link is a local blob URL — the file never leaves your device.

Frequently asked questions

What do the eight digits in the left-hand column mean?

They are the byte offset of the first byte on that line, written in uppercase hexadecimal and padded to eight digits. The first line therefore starts at 00000000, the second at 00000010, the third at 00000020, and so on in steps of sixteen. That is the same offset a debugger, a file-format specification or a patch note would quote at you, so you can jump between this dump and a written spec without converting anything.

Can a search hit start on one line and finish on the next?

Yes. Searching runs over the file's bytes as one continuous array, and the sixteen-per-line layout is purely how the result is drawn. A pattern sitting across a line break is found exactly like one sitting in the middle of a line, and the matched bytes are highlighted on both lines.

What can I type into the hex search box?

Hex digits, in any spacing you like. Spaces are stripped and so is a 0x prefix wherever it appears, so 4A50, "4A 50" and 0x4A0x50 all search for the same two bytes. Anything that is not a hex digit is refused with a message, and so is an odd number of digits, since a byte needs two. The text mode next to it encodes what you type as UTF-8 first, which means an ASCII word searches for one byte per character while an accented letter or an emoji searches for its full multi-byte sequence.

Which file signatures does the signature line beside the file name check?

Fourteen entries, chosen for how often they turn up rather than for coverage. PNG, JPEG, GIF87a and GIF89a, BMP, PDF, the ZIP local-file header that also fronts DOCX, XLSX, PPTX, JAR and APK, the end-of-directory marker of an empty ZIP, GZIP, 7-Zip, RAR, ELF binaries, RIFF containers such as WAV, AVI and WebP, and the ID3 tag that most MP3 files open with. Anything outside that list reports no match rather than a guess, and you are free to eyeball the opening bytes against a format specification yourself.

Is there a size limit, and what happens if I go over it?

The ceiling is 100 MB. The browser reads the file first and the check runs on the result, so going over does not crash anything, it just refuses to build the view and tells you the file's exact byte count alongside the limit. That cap exists to keep one enormous array from wedging the tab, not because the grid itself struggles, since the grid only ever draws the lines you are looking at.

Can I change a byte and save the file back out?

No. This is strictly a viewer, with no editing, no patching and no export. Everything on the page reads from the byte array the file was loaded into, and nothing writes to it. If you need to modify bytes you want a native hex editor such as HxD, xxd or a debugger's memory view; what this page is for is reading, searching and confirming, including checking a patch somebody else made.

Related tools