Overview
Renders your text as a canonical hex dump: eight-digit hex offsets on the left, sixteen bytes per row split into two groups of eight, and an ASCII sidebar where printable bytes appear as characters and everything else as a dot. The dump regenerates as you type, using UTF-8 bytes, and one click copies the whole dump in the classic offset-hex-ASCII layout.
How It Works
Type or paste text into the input field. The dump appears immediately in the monospace panel, one line per sixteen bytes, with offsets counting from zero in uppercase hex. Multi-byte UTF-8 characters show as two or more hex bytes, and their sidebar rendering collapses to dots unless each byte happens to be printable ASCII. Click anywhere in the dump to copy the entire formatted output, ready to paste into a bug report, a code review, or a protocol document.
Step-by-Step Usage Guide
- Paste the text or payload you want to inspect into the input field.
- Read the offsets on the left to locate a byte position of interest.
- Use the ASCII sidebar to spot embedded strings among the bytes.
- Click the dump to copy the full formatted output for a bug report or review.
Technical Specifications & Standards
The layout matches what tools like xxd emit: an eight-hex-digit offset, the hex bytes in two eight-byte columns for readability, and a pipe-delimited ASCII gutter. Three behaviors are worth knowing precisely. The byte source is the UTF-8 encoder, so a character like an accented e is two bytes, an emoji four, and the ASCII column only shows bytes 32 through 126; bytes from the second half of a multi-byte character are always dots even though they belong to a printable character, which is correct at the byte level and confusing at the character level. The tool's catalog entry promises byte editing, binary diff highlighting, and byte search, but the implementation is a viewer only: there is no file input, no editing of individual bytes, and no search box; editing happens by changing the source text, and the dump follows. Offsets are hex while row boundaries are decimal sixteen, so row 00000010 starts at byte 16, and the last row is padded with spaces rather than partial values, which keeps columns aligned when you diff two dumps of similar inputs.
Targeted Use Cases
- Inspecting protocol headers and magic bytes in a small payload.
- Working out how many bytes a UTF-8 string actually occupies.
- Comparing two encodings of the same text by diffing their dumps.
- Documenting a binary format in an issue with a readable hex and ASCII listing.
Notes & Gotchas
- Count multi-byte characters by their hex bytes, not by sidebar glyphs, when offsets matter.
- Remember the input is UTF-8 text; to inspect arbitrary binary, encode it first, since there is no file upload.
- Use the dot gutter to find non-printable regions quickly, then read their hex values in the columns.
- Copy the dump rather than screenshotting it, since text preserves alignment and is searchable.
Frequently Asked Questions
Can I edit individual bytes like a real hex editor?
No. Despite the name, this is a viewer: you edit the source text and the dump regenerates. There is no byte-level editing, file loading, search, or diff highlighting in the implementation.
Why does the ASCII column show dots inside a normal word with accents?
The sidebar only renders single bytes in the 32-126 printable ASCII range. Accented and non-Latin characters are multiple UTF-8 bytes, and each component byte outside that range appears as a dot.
How are the offsets counted?
Offsets are hexadecimal and start at 00000000, incrementing sixteen per row. Row 00000010 therefore begins at decimal byte 16. The final row is space-padded to keep columns aligned.
Can I load a file to inspect?
No. The tool takes typed or pasted text only and encodes it as UTF-8. To inspect a binary file, extract the region you need with another tool and convert it to text first, or use a desktop hex editor.