Binary inspection workflow
Hex bytes: offsets, exclusive ranges and byte order
A hex view shows the bytes that exist, not the format you expect. Choose the source encoding, locate the byte offset and make the interpretation explicit before copying a range into another tool.
Content updated: · Maintained by Hung Chi-Hsueh · corrections
Base58 represents bytes, not a verified address
Bitcoin Base58 preserves every leading zero byte as a leading 1: hex 000001 becomes 112 and decodes back to those three bytes. Choose Hex when the data is not valid UTF-8; interpreting bytes as text can hide control characters. Confirm the alphabet and preserve the complete result when passing it to another tool.
Raw Base58 conversion does not check a Base58Check checksum, version, address, ownership or safety. The local converter uses complete Hex pairs without separators and rejects malformed input; encoding is not encryption.
Choose bytes rather than guess their encoding
A local file is read as original bytes, preserving BOMs, NULs and line endings. Hex mode accepts complete pairs such as 00 01 7F or 00017F, separated only by ASCII space, tab, carriage return or line feed. A token containing an odd number of digits, 0x prefixes, offsets, hexdump ASCII columns and collapsed * rows are rejected; this is not a general dump reconstruction parser.
Standard Base64 mode requires the standard + / alphabet, canonical padding and zero unused pad bits. It does not guess Base64URL, unwrap data URLs or repair invalid text. An empty file has zero bytes and no valid cursor. Pasted source is limited to 1 MiB UTF-8 text, not 1 MiB decoded data: Hex and Base64 expand bytes, so their decoded capacity is smaller.
Offsets are zero-based and range ends are excluded
Offsets use decimal or an explicit 0x hexadecimal prefix. For the nine-byte sample 00 01 7F 80 FF 41 42 43 0A, 0x5 points to 41, the ASCII letter A. A range starting at 5 with length 3 is [5, 8) and contains 41 42 43; byte 8 is excluded. Invalid or out-of-file offsets and ranges are rejected, not clamped to a nearby byte.
The inspection cursor and export selection are independent. Moving the cursor changes the start of integer interpretation; it does not silently move the export range. Check start, exclusive end and length before copying or downloading. A zero-length range is explicitly empty, not a request to export the whole file.
ASCII and integers are labeled interpretations
The ASCII column shows bytes 20–7E as printable characters and every other byte as a dot. A dot can therefore represent many different original values. This is not UTF-8 decoding: a multibyte Chinese character appears as several dots. Use the text encoding inspector for a deliberate decode; copying a dump does not replace the original bytes with dots.
At the cursor, signed and unsigned 8, 16, 32 and 64-bit integers use the selected little- or big-endian byte order. The sample bytes 41 42 produce unsigned 16-bit 16961 in little-endian and 16706 in big-endian. A 64-bit value uses BigInt and remains exact beyond JavaScript Number precision. Too few remaining bytes is N/A, never zero padding. These values do not identify the field's declared type; floating-point interpretation belongs in the IEEE 754 inspector.
Search and export have separate limits
Search is an exact 1–256 byte Hex sequence or UTF-8 encoding of the supplied text, not a regular expression or locale-aware text search. Matches may overlap and span read chunks. Search runs locally in a Worker, with progress, cancellation and a 10-second timeout. At most 1000 offsets are retained; a capped result is explicitly incomplete, not a total count. A timeout is not evidence of no matches.
Local files are limited to 64 MiB and the view reads 256-byte pages. Text export is limited to a selected 1 MiB of bytes and at most 8 MiB of rendered text; over-limit copies are rejected without truncation. Binary download preserves the exact selected Blob slice, including an explicitly empty range. Page and search-result limits do not silently truncate a selected binary range.
A byte signature is not a safety verdict
Seeing PNG, PDF or ZIP-like starting bytes does not prove a valid file, trusted source or harmless content. The viewer does not detect formats, execute files, decompress data or certify malware safety. Downloads use a fixed .bin filename and are not automatically opened; opening the downloaded bytes elsewhere remains your own trust decision.
Input bytes, filenames, queries and selected offsets stay in page / Worker memory, not storage, URLs, request payloads or tool analytics. Clipboard and local downloads happen only through your actions. Clear the page to release references, but this is not a secure memory-erasure guarantee. Native Blob, Worker, DataView and BigInt support is required; errors are shown locally without a remote fallback.
Bytes: 00 01 7F 80 FF 41 42 43 0A
Cursor: 0x5 → 41 (A)
Range: start 5, length 3 → [5, 8) → 41 42 43
uint16 at 5: little-endian 16961; big-endian 16706
uint64 at 5: N/A (only 4 bytes remain)Data provenance