View files as hex dumps with ASCII representation. Search for patterns, identify file magic bytes, and analyze binary data.
A Hex Dump Viewer exposes a file as ordered byte values instead of relying on its filename extension or a text decoder. It presents hexadecimal bytes beside an ASCII representation, supports pattern searches, and helps reveal recognizable file signatures. The ASCII side is only a reading aid: it cannot faithfully display arbitrary binary data or multibyte text, so base conclusions on the hexadecimal values. File inspection happens in the browser, and the selected bytes are not uploaded.
A concrete input and expected output from the current implementation.
Input
A two-byte file containing exactly the ASCII text Hi, with no newline or byte-order mark.
Expected output
At offsets 0 and 1, the hexadecimal byte values are 48 and 69. The ASCII representation is Hi.
ASCII H has decimal value 72, which is hexadecimal 48. ASCII i has decimal value 105, which is hexadecimal 69.
Each file byte is represented by two hexadecimal digits, from 00 through FF. Consecutive bytes are grouped into dump rows and paired with an ASCII view when a byte corresponds to a printable ASCII character. Bytes without such a character cannot be represented faithfully in that side column. Position information relates a visible byte sequence to its location in the file.
Pattern search narrows inspection to occurrences of a chosen sequence in the byte stream. The first bytes are especially useful when checking common file signatures, also called magic bytes, because many formats define recognizable leading values. The viewer reports what is present; interpreting that sequence requires comparison with a format definition, and a matching signature does not establish that the remaining file is valid.
Treat each two-digit hexadecimal value in the data area as one byte. Use the accompanying position information to locate that byte within the file, and use the ASCII side only as a quick clue for printable text. Do not combine a row position with the data bytes or assume every displayed character represents a complete encoded character.
No. A recognizable signature can narrow the possibilities, but some formats share containers or related headers, damaged files may contain only part of a valid header, and deliberately constructed files can imitate signatures. Confirm important findings against the format specification and inspect structural bytes beyond the opening sequence. The viewer exposes byte evidence; it does not certify the file.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Generate strong, random passwords with customizable length, character sets, and complexity requirements.
Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.
Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.
Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.
Scan and decode QR codes from uploaded images or your device camera to extract embedded data.
Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.